Tatu,
no doubt about that. If you business demands storing a resource, REST will
not prevent you from doing so. But as you said, then this is because of it's
resource state, not of it's conversational state. The conversational state
still must not get stored on the server. So for sake of clarity, let's not
further use the carts example, as it would mislead readers. We should fina
an example where undoubtful the conversation state will never get part of
the resource state just be redefinitio of the business scenario. ;-)
Regards
Markus
From: Tatu Saloranta [mailto:tsaloranta_at_gmail.com]
Sent: Samstag, 20. Februar 2010 20:07
To: users_at_jersey.dev.java.net
Subject: Re: [Jersey] RESTful Ordering (was: JAX-RS == REST? Or not? (was
Re: [Jersey] What HATEOAS actually means))
On Sat, Feb 20, 2010 at 12:09 AM, Markus Karg <markus.karg_at_gmx.net> wrote:
Anyways, their storing of carts content of their servers was a business
decision, not a technical one. ;-)
Agreed. But I think it is an interesting case to consider -- I am sure that
persistency (and thus statefulness) of resources is a must for many systems.
And that it is necessary to separate resource state with session/transaction
state. I don't think REST would preclude former, but at this point I would
not be entirely surprised to be convinced otherwise. :-)
Actually come to think of that, I can see why someone might think of
shopping cart as conversation state... and others as more of a resource. I
guess that is modeling choice really.
And also a practical thing: if it is part of conversation, you can have
multiple concurrent sessions (open a new browser window, get a different
cart); or just a single shared one per account.
FWIW, for retailers like Amazon this is obviously a must feature; not just
shopping cart but wish lists and such. Although it is good to get immediate
sales, probability of a later purchase is probably high (I don't know the
ratio, nor could divulge if I did -- this is just inferred from public
information :) ).
-+ Tatu +-