On Feb 19, 2010, at 7:56 PM, Marc Hadley wrote:
> On Feb 19, 2010, at 1:08 PM, Kevin Duffey wrote:
>>
>> That said, I can see how REST could be used for the cart example... but (always a but) I am failing to see how anyone other than an individual client would want to use a pure rest implementation since the burden of maintaining state is put on them. By anyone other than individual, I basically mean a web site... where they cater to end users.. and thus have to deal with the scaling issues that maintaining state will put on them. It's the HttpSession/replication nightmare all over again.. although these days we're far better prepared to scale state than back in the late 90s when servlets and HttpSession were first being developed with and not many people had an idea how to replicate session data to ensure fault tolerance and load.
>>
> I think its an application decision how much state its wants to maintain. The shopping cart example is a good one, there nothing unRESTful about having a resource that represents a shopping cart. The key point is that any server-side state should be held by a resource rather than something ephemeral like session state.
The issue here was actually how the request must look like that initiates the purchase, not where the cart is being stored. Storing the cart in a session clearly violates the stateless server constraint with all known consequences (on scalability). Storing the cart as a resource is fine.
However, the purchase request must explicitly include the items to be purchased, otherwise the meaning of the request would depend on server side state and that violates the stateless message constraint.
>
> Personally I like the way my Amazon shopping cart works, I can use it from a variety of clients and the state of my cart is maintained on the server.
Which is not un-RESTful. Amazon does send the order details[1] in the last POST that does the purchase, so the message is stateless.
Jan
[1] Just checked. There is the total and I *think* the items, but it was hard to figure out from the codes.
>
> Marc.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
-----------------------------------
Jan Algermissen, Consultant
NORD Software Consulting
Mail: algermissen_at_acm.org
Blog:
http://www.nordsc.com/blog/
Work:
http://www.nordsc.com/
-----------------------------------