>There's nothing in the REST architecture that says that I need to do everything in "one shot" >by storing all this info in the client first. If I can get a resource identifier from the server, as I >described earlier, I should be able to refer to it in the future.
This is a very good point... I am interested in this scenario as well. Thus far, all my replies have been about single-shot (typical 1/2 hour session timeout) scenarios. But you make a valid point that a transaction doesn't always need to be done quickly. It could be days that an order is built up. I suppose the answer will be that the consume of your API must store that state across those days. I am sure Markus will say something along those lines.. that your service STILL doesn't need to store this state. The client consuming your API will need to store that state in some manner irrelevant to your service..and when ready, can then make more calls to your API with that data the the client saved, and your API should work just fine with this. Since your API is stateless.. the consuming client can simply save the cart (in my original example) to a local DB, file, whatever.. and later on make a call to add more items to the cart, or process the cart.. check
out if you will.. it could be months later, and your API should work just fine with this. I think I get how this all works now.
But.. see my response (posted a short bit ago) about the issue where a client is a web site... and THEY have to now worry about storing state (be it for 1/2 hour or across days/months).. when your API is designed this way (being truly RESTful), you are putting the burden of a web site consumer client having to now scale their site to handle their customers because the service you provide does NOT store state. Basically, the buck has to be passed to someone if you are not going to store the state. To remain a true REST api, you absolutely have to pass the buck to the consuming client. As Markus said in another reply, the resource state.. in the case of a web cart, the contents of that cart, is stored by the client. If your API allows for (and it should if it's truly REST) a transaction to occur at any time.. be it instantly or months later, it's still on the client to maintain the contents of that resource state... in this case, the client would store the
web cart contents somehow, and at any time later could simply submit the contents to the URI for checking out.
I would say this tho.. IF that is the case, you definitely want the consuming client to know that if they for example store the cart contents for a month, then come back they SHOULD do a GET call to get the URIs again.. and they most definitely should make sure the contents in the cart is still valid. This is probably outside the scope tho.. but just a thought I had with regards to this scenario.
So as long as a consuming client is a website... the development team of that site simply has to understand that a pure REST service they make use of will require them to maintain the state of the service they use.. and it may mean they have to handle scaling their sites to maintain that memory/state. It would behoove them to time out a session after a short time if that is the case..or store the data in a DB all the time and do some sort of periodic check to clear it out of a timeout is reached.