Loading ...
Sorry, an error occurred while loading the content.

Re: [rest-discuss] the meaning of stateless

Expand Messages
  • Jonathan Ballard
    HTTPS is not stateless because, simply, that expects credentials, session data, metadata, and or any secure transport layer. Dynamic resources are useful for
    Message 1 of 86 , Apr 20, 2013
      HTTPS is not stateless because, simply, that expects credentials, session data, metadata, and or any secure transport layer.

      Dynamic resources are useful for stateless HTTP with less round-trips. Simply again, the POST could create the resource and redirect response instead of store session cookies. These are useful in contrast for further POST, GET, PUT, and DELETE methods.

      Also note that ReST does not need to be directly implemented on top of HTTP. Queue analysis may further optimize round trips before transport.

      On Sat, Apr 20, 2013 at 7:33 AM, Brian Craft <craft.brian@...> wrote:

      I don't understand how the word "stateless" is being used in REST. Obviously POST and PUT create state on the server. Obviously, requests after a state change depend on that state change (e.g. by using a URL that was not valid before the state change).

      I can almost live with this usage of "stateless" for persistent objects stored on the server, because it can be thought of as not being "session state": it lasts longer than a session. But in any moderately complex web app, if you try to design a REST API you will quickly hit GET size limits when doing complex queries. And then the suggestion is to do something like POST the query parameters, returning a Location header for a "query" object that can be fetched with GET. How is that not storing session data on the server? How is that different from non-REST solutions?

      There are three obvious differences between POSTing a query and just generically using POST instead of GET. POSTing a query requires two round-trips to the server, bad for latency. POSTing a query and using a Location header limits the response to the creation of a single object, which is fine for 1990's full-page-load design, but is unrealistic for any moderately complex ajax app, where an API call will result in the creation of multiple objects (e.g. creating related images). And POSTing a query requires the tracking of large numbers of transient "query" objects, hugely complicating both client and server, the very thing REST is supposed to avoid.

      Perhaps to clarify what is meant in REST by "stateless" someone could give examples of things that *aren't* "stateless", and contrast them to REST.

    • Nicholas Shanks
      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
      Message 86 of 86 , Jun 11, 2013
        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.

        — Nicholas.

        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/purchase
            Content-Length: 0

        would be stateful and undesirable for conformance with REST whereas:

            POST /purchase
            Content-Length: 1234

        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 /purchase
            Content-Length: 0
            Cookie: client=12345

        seems 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 McClure

      Your message has been successfully submitted and would be delivered to recipients shortly.