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

Re: [rest-discuss] the meaning of stateless

Expand Messages
  • Mark Baker
    ... This is what I m talking about when I suggest focusing on the interface, aka the message. HTTP messages are generally sent between parties that know
    Message 1 of 86 , Apr 24, 2013
    • 0 Attachment
      On Tue, Apr 23, 2013 at 12:14 PM, Brian Craft <craft.brian@...> wrote:
      >> > Fielding's definition didn't do much for me, because the terms aren't
      >> > adequately defined,
      >>
      >> They are, and the definition is most definitely adequate, trust me on
      >> that.
      >
      >
      > I don't agree. Take this statement, for example:
      >
      > "Each request from client to server must contain all of the information
      > necessary to understand the request, and cannot take advantage of any stored
      > context on the server. "
      >
      > What does "understand" mean in this sentence? I'm not aware of a technical
      > definition of "understand" as it applies to computer systems, and it's not
      > defined in the paper.

      This is what I'm talking about when I suggest focusing on the
      interface, aka the message.

      HTTP messages are generally sent between parties that know nothing of
      each other, so "understand" here means exactly that; that the meaning
      of the message can be understood by the recipient so its clear what
      the sender is asking be done when it sends the message.

      > Again, take the "query by POST" pattern. The eventual
      > GET depends on a previous POST. Does the server "understand" a request that
      > depends on a previous request? What about "stored context"? One would
      > reasonably believe that POSTing a query creates stored context on the server
      > which later requests may take advantage of. But this sentence says that it
      > must not "take advantage of any stored context on the server." I assume this
      > apparent contradiction is due to some different use of terms, that "stored
      > context" doesn't mean what one would reasonably assume it means, or
      > something. If this is a different usage of the terms, they should be defined
      > somewhere.
      >
      > My current guess is that "understand" means that the communications layer
      > can read the request and generate a valid response, including the case where
      > the POST goes missing and it must return a 404: that it still "understands"
      > the request even though the app can't process it since the depends on a
      > previous request.
      >
      > But then it gets really odd with claims like "the server doesn’t have to
      > manage resource usage across requests." How is a POSTed query not a resource
      > on the server that must be managed across requests?

      It is, but the *meaning* of future messages doesn't change if the
      state of that resource changes.

      Mark.
    • 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
      • 0 Attachment
        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
            
            items=...&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 /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

        --
        Matt McClure
        http://matthewlmcclure.com
        http://www.mapmyfitness.com/profile/matthewlmcclure

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