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.
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.
Marc.