Web Things, by Mark Baker

Jorgen Thelin references Bill de h&#211ra’s blog on session state.

Unsurprisingly, it appears there’s some serious misconceptions about state going on here. As Ken Arnold said, “State is Hell”, which jives with my experiences.

Bill writes;

One issue with the REST hypertext model is its view on managing state. REST constrains that state reside on the client, However the real web works precisely backwards to this: all interesting state is kept on the server, as sessions.

That second sentence is incorrect. Even cookie based Web apps still keep most application state on the client. If they didn’t, you wouldn’t be downloading web pages. The only architectural style I know of that keeps all state server-side is the Remote Session style, ala VNC.

And when exprienced enterprise practitioners like Martin Fowler say that state belongs on the server, it makes you wonder whether REST has anything to offer here.

I’d have to see a reference. I’d be very surprised if Martin said this in the way you’re implying he meant.

Then Jorgen writes;

[…] my hunch is that REST can’t provide a clean solution to the general category of “conversation” style applications (involving server-controlled request state transitions) which is the more usual meaning of the concept of “session state”.

I’m a fuzzy on what Jorgen means by “server-controlled request state transitions”, but I know that REST can handle what’s commonly called “session state” quite well. Moreover, even HTTP can handle it, without any extensions or use of cookies. All that’s needed is a client side implementation which manages state better. For example, rather than implementing “shopping carts” as a server-side container resource for shopping items, implement it as a generic client-side container, where the shopping/checking behaviour is a result of POSTing a representation of that client-side container to a checkout processor on the server. This generic client-side container would be useful for holding any application state, and therefore anything you’d want to do as a session.

There’s all kinds of pros and cons to this of course, as there is with any solution developed within the bounds of any architectural style, but REST can do it without batting an eyelash.