Re: [rest-discuss] the meaning of stateless
- Hi Robert,Thanks for taking the time to explain.I sense that it's a really good explanation analogy but reading through it I got lost on how "you" and "me" and especially "sales rep" and who was actually building the house et. al. and how to all relates to "client" and "server" in a web API interaction. I guess I'm just feeling a bit dense on this topic...-MikeOn Apr 25, 2013, at 3:47 PM, Robert Brewer <fumanchu@...> wrote:
Markus came closest when he distinguished "application state" from "resource state". But even that doesn't quite go far enough until you define what an "application" is and understand what "state" is.
Lots of web developers think an "application" is "the code I wrote in Python or Ruby that runs on the server." But that is worlds apart from the way Roy uses it. He uses it in its original sense of "accomplishing a goal with something". Building a house is an application of (among other things) boards, nails, and a hammer.
Lots of web developers think that "state" means "data in my database". But that is worlds apart from the way Roy uses it. He uses it in its original sense of "the current node in a state machine." Let's say you supply boards and nails. If my application is "building a house", the "state" of my application is not how many boards and nails you have. It is not even how many boards and nails I have. It is how much of my house has been built. The state is advanced by building walls and assembling them together. Those have sub-states, some of which involve buying more boards and nails.
The interaction between me and you is "stateless" if I can buy boards and nails from you without you knowing anything about how much of my house has been built, or even if my application of what you provide is "building a house". If I have to talk to the same sales rep every time then it's not stateless. If I've bought 100 board feet and you pre-order another 900 board feet from your vendor because I'm building a house then it's not stateless. If you keep 1000 board feet on hand because building a house is a very common operation, then it might be stateless, because your business doesn't know anything about my application.
Now let's say you not only provide boards and nails, but also hammers, and plans, and labor, and installation. In fact, the house is built by you on your property. But I get to pick out the floorplan and curtain colors. The application has not changed. The state machine has not changed. The methods used to advance the application from one state to the next have not changed. What has changed?
1) Who does which activity to advance the state machine. Most of it used to be me. Now most of it is you.
2) Where the current node of the state machine is kept; that is, how much of my house has been built. That information used to be kept on my property. Now it is kept on your property.
The interaction between me and you can no longer be "stateless" because you know how much of my house has been built. If I ask you to change the floorplan or the curtain colors, first you have to authenticate me, and then you have to go to the property to inspect the state to see if you can comply with the request. That's two scalability problems you didn't have before. It doesn't mean you're not raking in the dough. But I'm no longer advancing the application state except at two points; in many cases, I'm not even doing that--I'm configuring the application state machine instead.
- 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--