RE: [rest-discuss] the meaning of stateless
- On Friday, April 26, 2013 12:44 AM, Mike Schinkel wrote
> On Apr 25, 2013, at 4:15 AM, Markus Lanthaler wrote:Great!
> > 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.
> > For example, if you browse through a paginated collection the serverRight, although in that case it isn't a session. It's simply a user
> > 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,
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 :-)Glad I could help.
> 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.
> As far as batch goes though, as a means of providing atomicity over aOf course you can achieve atomicity in a RESTful system. The easiest way is
> 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
> If Markus Lanthaler's explanation was current then it is resource
> state and thus actually RESTful. Or is that wrong?
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:
- 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--