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

RE: [rest-discuss] the meaning of stateless

Expand Messages
  • Markus Lanthaler
    On Friday, April 26, 2013 12:44 AM, Mike Schinkel wrote ... Great! ... Right, although in that case it isn t a session. It s simply a user identifier that you
    Message 1 of 86 , Apr 26, 2013
      On Friday, April 26, 2013 12:44 AM, Mike Schinkel wrote

      > On Apr 25, 2013, at 4:15 AM, Markus Lanthaler wrote:
      > > That's true and I think that's where your confusion comes from.
      > > There are indeed two types of states: application state and resource
      > > state.
      >
      > Finally! I think that comparison phrase "application state vs resource
      > state" illuminates what I'm been struggling to understand, thank you.

      Great!


      > > For example, if you browse through a paginated collection the server
      > > must not keep track of the last page the client visited. That's up
      > > to client.
      >
      > This was a helpful example. I can see now that the page a client is
      > viewing is nothing about the collection but instead it's about the
      > client's current view of the collection. The fact the page changes
      > does not change the collection in any way.
      >
      > As a further example if I had a session that kept track of the layout
      > the client wants to receive, i.e. tabular vs. card view that would
      > also be application state.
      >
      > OTOH, if the purpose of a session was ONLY to keep track of the ID of
      > the user then that would seem to be no different from an auth header
      > cookie that authenticates the user. And that kind of session would not
      > be bad because it's about client identity and not application state,
      > right?

      Right, although in that case it isn't a session. It's simply a user
      identifier that you are sending. If you map a session ID (with a limited
      validity period) to a user ID then again it would be stateful.


      > > No need to apologize :-)
      >
      > Thanks again for humoring me on my quest for understanding. I think
      > I've gotten a much better handled on it on, thanks to you.

      Glad I could help.


      > As far as batch goes though, as a means of providing atomicity over a
      > stateless protocol, no, I can't imagine that it can be done RESTfully.
      > Somebody might prove me wrong though as I haven't given it much
      > thought.
      >
      > If Markus Lanthaler's explanation was current then it is resource
      > state and thus actually RESTful. Or is that wrong?

      Of course you can achieve atomicity in a RESTful system. The easiest way is
      to include all data in a single request. In the best case that request would
      be idempotent so that you can safely repeat it.

      What you mean however (I think) are transactions. If transactions span
      multiple services I have to admit it gets tricky. But that's the case for
      all distributed architectures and a reason why you try to avoid transactions
      whenever you can. They do not scale. To get an idea how this could be done,
      you might wanna have a look at Cesare's presentation:

      http://slideshare.net/cesare.pautasso/atomic-transactions-for-the-rest-of-us


      Cheers,
      Markus



      --
      Markus Lanthaler
      @markuslanthaler
    • 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
            
            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.