Re: [rest-discuss] the meaning of stateless
- These are separate issues.From a REST perspective, HTTPS is absolutely stateless, because it is orthogonal to the application state. TCP itself is a stateful protocol. We just don't see it at the application level. The application is ignorant that I've dialed the modem, had it connect it's carrier waves and that it's handshake and compression are working before I tunneled PPP over it in order to stand HTTPS on top of that.All of those are stateful in their own right, but have no effect on the application.
On Mon, Apr 22, 2013 at 10:13 AM, Brian Craft <craft.brian@...> wrote:On Mon, Apr 22, 2013 at 3:09 AM, Matt McClure <matthewlmcclure@...> wrote:On Apr 21, 2013, at 7:52 PM, Brian Craft <craft.brian@...> wrote:Fielding's definition didn't do much for me, because the terms aren't adequately defined, and there aren't enough examples to clarify his intent. Also, some of the claims seem to be at odds with practice. Again, the "POST to query" thing involves storing state between requests, while Fielding says RESTful APIs are better because of "not having to store state between requests". Well, which is it?I think a key distinction is creating and destroying resources vs. other kinds of state. The former is a key feature of REST.That's very much the impression I'm getting: that it's not generically server-side state that is the key issue. It's something to do with the difference between explicitly created state that can be directly referenced with a URL vs. implicit state. If that is what it's about, then "stateless" should be qualified, and some of the claims should be relaxed.
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--