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.
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”.
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.