views:

66

answers:

2

We are re-developing our buyonline functionality and we are doing it the RESTful way.

The process is a three step one and the customer is asked to enter data at each step.

Let's say the three URL's are;

/step1.aspx

/step2.aspx

/step3.aspx

Each step is pretty autonomous and don't require data from any of the other steps.

The question is how do I stop customers directly navigating to step2 w/out first completing the details in step1 given each step knows nothing about the previous step?

I know I can add a property to my object model telling me which step was the last one etc but doesn't that kinda break the whole REST principle?

I also don't want to check my model as to whether details in a previous step have been fileld in because again that violates REST principles.

I think I'm slowly resigning myself to a concept that I need (something) to tell me where I have been but I don't want that.

Should/Can the controller perhaps detect that the history doesn't contain the previous step placing control back to where I think it should be?

+3  A: 

REST URLs are supposed to represent entities. e.g. books / orders / photos etc.

I think the confusion above is that you're trying to represent a booking sequence in REST terms as entities, and (of course) they're not. So the objects that your customers can select, their orders etc. may be usefully represented in this fashion. Other elements of the process shouldn't be.

You may argue that step 1 represents an address (for the sake of argument). But POSTing an address object is distinct from entering that data in a form and permitting navigation to/from related pages. That operation has a sequence or flow to it, and is conceptually richer than simply POSTing/GETing/DELETEing an address. You've illustrated this by arguing you want to prevent someone completing step 2 without completing step 1 etc.

Brian Agnew
A step in some kind of registration process could be an entity too. The resource "step1.asx", for example, could be a mapping to the entity that represents some kind of license agreement.
hrnt
Each step in the process does represent an entity. step 1 accepts the product, step 2 the customer details and step 3 the payment details. is this what you mean?
griegs
And to be precise, resources in REST are not actually entities, they are mappings to sets of entities.
hrnt
@hrnt - can you publish a reference to your comment re. resources ? I would expect a URL of (say) http://localhost/photos/1 to point to a single entity.
Brian Agnew
http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_2 and see 5.2.1.1, first paragraph. The idea is that the resource localhost/photos/1 can map to a single entity "photo of a cat", but the resource itself is not the entity. For example, there might be other resources that map to the same entity, such as localhost/photos/recent. Note that a single entity is still a set (with just one element).
hrnt
@hrnt - thanks for that link
Brian Agnew
@hrnt You have to be a bit careful with the term entity as it is a very overloaded term. I think all Roy is saying in that paragraph is that the contents of the resource can change over time. E.g. /Weatherservice/Montreal/TodaysWeather may not have the same values tomorrow as it did today. I don't think he is using entity in the DDD definition of the term, or in the database Entity-Relationship term. He is using Entity in the HTTP context where it just means the set of bytes that are returned in the body of an HTTP request.
Darrel Miller
@Darrel, It is defined in the context of that dissertation. Entities mean values in that context, and values are either resource representations or resource identifiers. Indeed, the point is that the membership function can change over time. The resource ("/photos/1") stays the same, but resource representations (= entities, for example "photo of a cat") that the resource maps to can change.
hrnt
+1  A: 

When going from step1.asx to step2.asx, pass a query parameter that contains some key that tells the server that step1 was visited. For example, step1.asx has a href to step2.asx?whatever=a92jv29.

The "a92jv29" can be, for example, encrypted timestamp from the server. You can easily verify that it is valid (not expired and not from the future) in the server side. No need to store the state.

Your URL's could have better names, should as "terms.aspx", "registration.aspx" or whatever but that is strictly not necessary.

hrnt
They're not actualy step1 step2 etc. that was just for brevity. :) But this answer makes some sense to me.
griegs