Re: [rest-discuss] the meaning of stateless
- The transaction is the same thing. Think of the transaction as renting bowling shoes. In order to go bowling, you must have bowling shoes. So you "check out" the token (bowling shoes), and give them YOUR shoes as an "identifier", then you go back and swap them out. When you check your bowling shoes back in, you're done bowling. Any person at the counter can handle this transaction. The actual transactions themselves are stateless. You're just pushing resources back and forth.Just like when you go to the Post Office. You get in line, and when you get to the clerk you ask to change your address. They tell you to fill out a form, and you go back in line. When you get back to a clerk, any clerk, the process continues. The state itself is the form you're holding. You don't have any requirement to go back to the same clerk.Now, if you replace the name/address resource with "Shopping Cart" it's the same thing. A Shopping Cart is simply a combination Invoice and Pick List that's being built up over time. There is machine logic to keep the resource properly structured and semantically correct, but it's really a single resource that just getting changed over time. No big deal.It's also not inconceivable to have other operations that may make changes to that resource. Perhaps if I add a business address through a separate mechanism, the name resource may get added to it.It's also straight forward to consider that I can PUT a new copy of that resource when I move, changing the city and state etc. within the resource. Right?It's safe to say that someone's name and address as a resource is a pretty straight forward resource:These are both fine. The stateless attribute is an attribute of the transaction in place, not a specific resource.For example
However, each of the transactions that manage that resource are themselves stateless. Resource value is not the same as state. You can easily see having any of a zillion web servers fronting the resource store that manages the Shopping Cart. Since there's no transaction state maintained with any one server, you can switch back and forth across them without any semantic change to the application.
On Mon, Apr 22, 2013 at 12:42 PM, Mike Schinkel <mike@...> wrote:
This has been a really insightful thread. Thank you Brian for starting it.After 7 years of trying to fully understand REST I'm still discovering nuances that are not clear, such as "the meaning of stateless." If I were better at understanding abstract explanations I would probably be much farther along but I'm just no good without a lot of relevant examples that illustrate the associated principles.To that end I'd like to ask about some examples?
1.) Shopping cart: We have a web API that allows a user to add items and the server keeps track of the items in my shopping cart. For example a shopper would first add items to their shopping cart which behind the scenes would POST to a "new cart" resource, (B 1..n) POST to a "new item" resource for each item to be purchased, (C, D) PUT billing and shipping addresses to the cart, (E) PUT payment information and finally (F) PUT a "order-placed" value to the cart to place the order.2.) Batch Operations: In "RESTful Web Services" in the section preceded a few pages by the section "Why Stateless Matters" they recommend to use "Batch Operations" for transactions such as the archetypical "move funds between checking and savings accounts" example. Specifically they suggest (A) POSTing to get an account transfer transaction ID, (B 1..n) PUTting the new balances to the different accounts, and then (C) PUTting to the account transfer transaction ID to complete the transaction. And they make no mention of this approach being stateful after just writing about statelessness.Are these examples stateless, or not? Are they RESTful, even if they use resources and hypermedia, et. al.? If they are not RESTful then does that mean they are doing it wrong from a use-case perspective or that RESTfulness needs to be evaluated like other criteria, i.e. performance, ease of development, et. al?-Mike
CONFIDENTIALITY NOTICE: The information contained in this electronic transmission may be confidential. If you are not an intended recipient, be aware that any disclosure, copying, distribution or use of the information contained in this transmission is prohibited and may be unlawful. If you have received this transmission in error, please notify us by email reply and then erase it from your computer system.
- 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--