« Exceptions considered pointless | Main | Nick Chalko: versioning 101 »

REST and session state

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. 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. On the other hand after you've built your tenth session backed web site, you start to realize that managing state for users can get complicated and expensive, fast. However, Paul Prescod had this to say on the W3C TAG mailing list:

I think that in most cases there is virtue in making temporally extended sessions into URI-addressable, HTTP-retrievable resources. HTTP does not itself have a notion of temporally extended session, but neither does it have a notion of "map" or "auction" and yet it delivers representations of resources of those types. I don't dispute that HTTP has limitations. But I think that there is a lot of "shortcut thinking" when it comes to enumerating those limitations. "HTTP doesn't have X as a first-class concept therefore HTTP is not appropriate for X." That needs to be demonstrated, not asserted.

Exposing session state as resources. That seems like a start towards understanding how REST and the web might be squared on state management.


January 29, 2003 12:24 AM

Comments

Bruno Dumon
(January 29, 2003 02:36 PM #)

We did something like this in our xReporter database reporting tool (see http://xreporter.cocoondev.org -- there's an online demo).

Instead of keeping track of report parameters in the user's session, all state is kept in a temporary "report instance" resource.

Some nice side-effects of this are that URL's can be copied to another browser or mailed around and that the user can run multiple reports simultaniously in different browser windows.

There's still one reason though that we use cookies to track the user: to remember if (s)he has logged in. This could be solved by using basic authentication (it's a simple switch in the web.xml) but most people don't like this.

Jeffrey Winter
(February 6, 2003 01:54 PM #)

"Exposing session state as resources..." At one level this just seems like URL-rewriting with a veneer of REST rhetoric. Session-based, cookieless applications as a matter of practice use URL rewriting to maintain session affinity, tacking a session identifier to "base" URLs. This is the case whether the application follows REST principles or not. It's obvious that an application that is otherwise RESTful can create session affinity by the simple application of a session identifier in the URLs and maintain is RESTful qualities. To me the real issue is whether or not: one, the underlying application is "conversationally" stateful or not; and two if any important state is hidden (e.g., the Google API's hidden daily counter.)

I wonder what Fowler was really getting at. It seems orthogonal to REST where the state is maintained so long as it is accessible. Perhaps he's refering to the fact that if it is on the server it can be accessed from multiple clients. It may also be more reliable and hardened - especially in the case of thin clients.

Trackback Pings

TrackBack URL for this entry:
http://www.dehora.net/mt/mt-tb.cgi/902

Listed below are links to weblogs that reference REST and session state:

» REST and Session State from TheArchitect.co.uk - Jorgen Thelin's weblog
Bill de hra posts some ideas on adding session state to a REST-based approach, based on some comments by Paul Prescod : REST constrains that state reside on the client [...] [but] when exprienced enterprise practitioners like Martin Fowler say that st... [Read More]

Tracked on February 4, 2003 03:33 AM