Re: [rest-discuss] the meaning of stateless
- On Apr 24, 2013, at 9:34 PM, Mark Baker <distobj@...> wrote:Thanks for the reply.
Okay, can you explain a broader view? An approach this is not stateful?
Remember the days before electronic banking when we had to fill out
slips and submit them to a teller?
"amount": 300 }Yes, of course.But you did what I was afraid of as I was writing my question; you took my example where I deliberately broke out into multiple requests to *illustrate* situations where state across requests is required and you changed it to be trivial which seems to imply there are no applicable use-cases that need multiple requests.The 2nd reason I chose that example is because it was effectively the same as the recommendation for "batch operations" that Richardson & Ruby used on page 230 of RESTful Web Services, First Edition which followed page 222 that explained why "stateless" is so important. This implies either batch operations are not the same kind of state that Roy admonishes against, or that Richardson & Ruby where blissfully unaware of the irony of that recommendation juxtaposed with the discussion of the stateless requirement just 8 pages apart. And if the latter then I would ask it is even possible to create a RESTful system that has batch operations?Anyway, let me take your example which I assume is RESTful and ask my question another way. It seems to me that if I started with a state of "500" in account "12345" and "0" in account "12346" and do your POST example I end up with "200" and "300" in the accounts, respectively.However if I now do your POST example *again* it will fail, because I don't have enough money in the "from" account to complete the transaction. So how are the account balances not "state" in the context of Roy's "stateless" requirement?If you tell me the reality is that most non-trivial uses-cases for a web APIs actually need to be stateful in some ways and that the "stateless" requirement for REST is an ideal that has benefits when it can be achieved but is often impossible to realize then I think I'd be finally coming to an understanding of the stateless requirement. :-)But if you say "No, stateless can be achieved in most cases" then I'm even more lost than when I started asking questions on this thread a few days ago. :-(-Mike
- Like the SMS example, this is another case of trying to avoid server state (i.e. be RESTful) in cases where the server needs to keep a permanent record of the transaction anyway, one per client. Statelessness is about avoiding the word "my". Pay for the items in my basket, vs Pay for the items in basket #54203. Replicating session files between load-balanced servers may even be cheaper than replicating database-based resources.As the linked post says: "Most of the value cases for REST apply to repeatable responses, not an application that can't be reused, can't be transformed, and can't be shared.""I do not believe in trying to apply all of REST's constraints unless there is a reason for doing so."Just because an architecture is good for document retrieval, doesn't mean it should be mindlessly applied to everything else too.Perhaps the next Roy Fielding can come along and deduce the optimum architectural constraints for a private, non-repeatable, yet scalable application, and from these direct the evolution of HTTP just as HTTP 1.1 was informed.
On 9 May 2013, at 19:27, Matt McClure <matthewlmcclure@...> wrote:
On Thu, May 9, 2013 at 9:43 AM, Bob Haugen <bob.haugen@...> wrote:
Eric Bowman wrote:
> My nutshell explanation of REST from 50,000ft is that a system
> designed to manipulate shopping carts MUST be based on
> transferring actual representations of shopping-cart contents.
I hesitated to get back into this issue after having lost an argument
with Mark Baker about it a couple of years ago, but: the typical
behavior of a system that saves shopping cart contents on servers
(e.g. Amazon) is to send a representation of the shopping cart
contents back to the client to confirm the order, in which case, a
representation of the shopping cart contents then gets sent back to
the server from the client.
Would e.g. Mark and Eric agree that this is RESTful?I've also been following this conversation as a lurker. If I understood some of the earlier comments, it sounded as though someone made a case that a request like:POST /cart/12345/purchaseContent-Length: 0would be stateful and undesirable for conformance with REST whereas:POST /purchaseContent-Length: 1234items=...&in_quantities=...&with_payment_method=...would be more RESTful and less stateful.I guess I'm unclear why the former would violate statelessness. The state in the former is resource state, identified by an implicit /cart/12345 resource (assume I got the /cart/12345/purchase link from the cart resource).To contrast:POST /purchaseContent-Length: 0Cookie: client=12345seems decidedly stateful because it requires shared state identified by the ID in the Cookie header rather than the URI to disambiguate which thing the client wants to purchase.It seems to me that a client need not include all of the detail of the cart contents and payment method in the purchase request to conform with a statelessness constraint. I'd be happy to hear why I'm wrong if I am.Matt--