RE: 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:
> > 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