According to Roy Fielding (one of the principle authors of the HTTP specification) in his seminal thesis Architectural Styles when discussing REST, he mentions:
[E]ach request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server.
By “stored context” he’s referring to application state e.g. what the page number for the next page is vs. resource state e.g. any data store, image etc. – which is arguably the whole point of REST.
Is it fair to say that most attempts at pure rest (hereby defined as an implementation that conforms to the above thesis) must fail due to their reliance on storing session data on the server (persistent or otherwise)?
The concept of a session is common – in particular to Web developers – but is it RESTful according to the above definition?
4
I would say yes, session state does make a RESTful app non-RESTful. Trivial example, my sister subscribes to the Wall Street Journal. On a regular basis she will be reading something behind the paywall and decide to send a link (via her own email client, not via WSJ) to a friend who does not have a WSJ account. Click, send, fail. Clearly my sister’s experience at that URL is different from her friend’s.
Related, but not strictly on-topic: I am in the early design phase of a application designed to support significant research efforts on the net (called quests (think: bookmarks on steroids and LSD)) . The owner of the quest wants to share a particular view of his/her data with someone else, but this view requires a combination of UI state (e.g. which visualizations of what data are showing in which panes) along with appropriate permissions to access the UI and the data displayed. There’s a lot of stored-state required for the recipient to get the intended view.
My current solution is to store all of the UI/ACL/whatever info necessary for the view in a separate object and return the URL (probably a UUID) for that object. I believe that accessing the view object could be considered RESTful in the sense that everyone in possession of it gets the same info/experience.
5
Do server-side sessions violate REST?
They definitely do! When you implement REST, there must be no server-side session, otherwise you have a hybrid RPC/REST solution.
The client must send to a RESTful service all the context necessary to service the request, including the information necessary to authenticate the client, each time a new request is made. The server is free to cache information to make servicing subsequent requests faster, but the cached information must not amount to a server-side session. In other words, the request itself must contain enough information to be processed even in the absence of the cached state.
The most important point of REST is that an URI to a ressource always points to the same ressource. So users can pass around a reference to this ressource and everyone sees the same. This is called Representational State Transfer (REST). If the server keeps state and delivers a different ressource for the same URI, I would say this is not pure REST anymore.
4
Probably depends on what you mean by “session data”. Is that a precise term?
Secure communication between two parties often involves the server to generate (and store) a time-limited “access token” which the client has to supply with each request as a manner of authorization. This access token already is what I’d call “session data” – it is stored server-side, time-limited and related to one client (usually his permissions).
I’d be very surprised if this kind of operation was labeled as non-RESTful. OAuth is an example.
I’m not a specialist and I’m not very confident here; I’m just sharing my insights hoping they prove helpful.
What Fielding meant by that statement is that the application server hosting the REST API does not associate ambient state with a request by some sort of behind the scenes mechanism. Consider the difference between an application server and a database server. The REST constraint is that the application server should be stateless. However, the application server can delegate requests for resource state to the database server based on information which is part of the request, such as a user/password combination in the Authorization header or the Uri itself. After all, REST is based on the client/server model.
Sessions are basically used to add state to stateless, RESTful applications. So formally, this makes your RESTful application stateful, however having the server keep state makes your life a little easier, since you don’t have to pass all the data back and forth on each request/response.
Sessions, and more generally state, lets you avoid this, and this has some positive benefits in performance (less data transfered) and security (less data available to tamper with).
So while it officially violates part of the definition of REST, it’s so useful that it’s rare to see RESTful applications that don’t use state via sessions.
2