Please see inlined.
>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.
I think we must define what we like to reach. I always was talking about a
typical consumer that comes to a supermarket, walks through the aisles,
fills it's car, pays, and is through after half an hour. Now we have a new
scenario: You *want* to provide your customers a server to store their
filled cars somewhere in the basement until they come back after days. Ok,
now this is a business requirement, and you *want* to have it, so it is
perfectly valid to provide an API that will do that. But I think we agree
that this is a particular *wish* of this particular scenario, and not the
typical idea of a shopping cart in generel, so how should I know at the
start of discussion?
As you see, whether something is workflow-state or resource-state in fact
*can* rely purely on definition of the business requirements!
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.
Again, if you *want* to provide a service that persistently stores
half-filled shopping cars on *your* server in favour of your customer, this
is a *business* requirement. It is absolutely valid to put the cart in the
basement and give the customer a ticket (URI) to get it back later. The API
to provide that *can* be done in a RESTful way. But unless you *want* to
provide that (unless it is *not* part of the *business* requirements),
unless no customer would expect that its cart is still there after shutting
down the client and rebooting it (actually I won't -- the typical
supermarket will empty my cart at night since they would think I have just
forgotten to take this stuff home with me when leaving the shop), unless
that all becomes true, you have no *need* to store on the carts the server.
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.
As I said, if you *business* requirement is a service of that kind, then you
certainly can do that. But it was not clear to me that you customers expect
that service, just as I do not expect that my cart is still filled when I
come back to Walmart after one month.
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.
Well, I think a company able to drive a server farm for a front end shop
will understand what REST is and what the pros and cons are. Either *you*
have the power to enforce *your* solution, then *you* spare lots of
resources (YOUR money), or *they* have the power to enforce *their*
solution, then spare lots of resource (THEIR money). As you see, this is not
about technology. It is about business services and contracts.