A part of REST is the "client-stateless-server" part, abbreviated as "stateless". RESTful interactions are stateless. But that does not mean the resources are stateless (as said in what looks to be an otherwise nice presentation by Dan Diephouse, via Stefan Tilkov). On the contrary, resources are an embodiment of state. They have state that can be manipulated. They should not do per-client sessions, that's what stateless means. There should be no state but resource state between two client requests.
Repeat after me: Resources should be sessionless!
Posted at 1922 on Wed, Jul 30, 2008 in category Work | TrackBack | Comments feedA clear explanation of what stateless means in REST is that "resources hold resource state and clients hold application state".
Posted by: Tomas at August 8, 2008 2:43 PMThanks Tomas. I've seen this definition before (putting "application state" on the client), but I don't like it - I think the "application" rather encompasses the whole shebang - the database, the business logic, the Web front-end, and the client interactions with it. I prefer to think of it like this:
1) Application and resource state live on the server, in the database/content of the Web App, e.g. products, prices, delivery status on Amazon, pictures on Flickr.
2) User state mostly lives on the server, e.g. user preferences, stored personal info, stuff such as wish-list on Amazon, friends on Flickr.
3) Session state would then be the state of a fairly short-lived complex interaction between the client and the server, e.g. a shopping basket on Amazon, position on a map in Google maps, and the "current" user ID manywhere.
Resource state is a part of application state as I see it, but it should not be touched by session state. There are reasons why parts of the session could be on the server, but then it should become resources.
Posted by: Jacek at September 5, 2008 12:00 AM