I like the philosophy of the REST style, but I also have a major beef with it. Before getting in to that, let’s first define what REST is. Right now, there are two flavors of REST. One is the real one, as described by Dr. Fielding in his dissertation. The other one is what is merely any web service that uses HTTP, URIs and Json as its mechanisms.
The original REST pattern lays out how to architect application mimicking a world wide web of discoverable resources. The biggest differentiator from other architectures is that the all application state lies within the traversal of the links and nowhere else (just like your HTML surfing). In REST there should be no preconceived knowledge about what interfaces the application eventually will expose and there must not be any session state at the server as each request should be processable in isolation.
There is some friction as Dr. Fielding rightfully feels that many call their non REST styles REST when they fail to meet the criteria of the defintion. If he was ever to read this blog, I would probably add to that friction. I think that maybe the error is not only with the people; but to some degree with REST itself.
As opposed to HTML and the word wide web, REST allows for the imperative manipulating state on granular web resources. The problem is that REST does this without any server state resembling a session. To me, this is simplistic and fails to factor in important foundations and learnings in computer science. The session becomes to the RESTful developer what money is to communism; when trying to get rid of it, it become your biggest problem.
Let’s first look at the most popular REST implementation: the world wide web and hypertext. Using browsers, we traverse hyperlinked text documents using the GET verb. Everything follows the REST philosophy beautifully. When this works so great, why would not REST work equally great for web applications?
First we need to acknowledge a fundamental difference. HTML is a declarative language and all resources are read-only. REST applications are imperative and resources are mutable. No matter how we want this to be a new brave world, the theorems of information technology will show their ugly faces and they will ignore the beauty of the declarative hyper text documents that are free from side effects due to their read only nature.
What are the real world implications, you might ask? What is the real practical problem? The first apparent problem is atomicity. REST requires that the resources should be fine grained (“… people perceive a need for batch operations because they don’t understand the scope of resources.”). But what if we withdraw the money of the hotel booking but fail to make the reservation if there is no state allowed between requests? Fine grained resources, no batch operations and no sessions is simplistic. The next thing is user authentication. In the real world, we don’t want some unknown person to cancel our hotel reservation. Heck, ask any Wikipedia error how far he could go in 2012 without logging in. In the real world, the server needs to keep information about the user. If this is allowed in REST, an interesting question arises: from a philosophical standpoint, what is the difference between the server keeping metadata about a user and a server keeping metadata about a session other than expected lifespan?
As an experiment. Read the paragraph below. First using the word “user” instead of “smurf”. Then read the same paragraph using the word “supervisor”. Lastly, read the same paragraph with the word “session”.
Smurfs survive multiple requests. Smurfs are often associated with a password for authentification. The server keeps data on the smurf as the client cannot be trusted to say if he is allowed to cancel the hotel reservation or not. Therefore a surf must be created at the server prior to receiving a series of requests. Smurfs can be added to the server. Smurfs can be deleted from the server. According to REST, all information needed to perform a request needs to be provided with the request. As a consequence, REST does not need a session. Each request provides a reference to the smurf such that operations can be authenticated.
Again, the only difference is lifespan. My point is that the stateless server is either a delusion or a bad idea. It all reminds me of a story about a small village in Sweden where people discovering that they did not need money. It was the work of the devil. They happily told the press that, instead, they wrote small notes to keep track of services they performed to their neighbors. In this way they could trade their services for other services in the future. Instead of money they now had pieces of paper with value attached to them.
For many wanting pure REST and have bet their good name that it will work, the session and its shameful state is disguised with new names and clothes and sneaked back in. I think my favorite quote from Albert Einstein comes handy once again: “make things as simple as possible, but not simpler”. I think this should be foreseen in the pattern and that the pattern should evolve.
The good news is that must need not be a conflict. All we need to do is the recognize that the boy named Harry in the cupboard under the stairs do in fact exist and that he deserves our love. His magic is welcome and it will make our lives easier, not more difficult. We need session state to manage sets of imperative changes over time. Dr fielding already acknowledges the need for fine grained resources and does not approve of batch operations. Why not embrace the session as one such resource? And even if your imperative DELETE verb looks and smells like the GET verb, and that using URIs and HTTP, that we love for its simplicity, brings the smell of the simplicity of the functional web, we cannot hide the fact that we are not merely traversing static data any more.
The solution is to not to continue to believe that the world is a nail just because you’ve got a hammer. Dr. Fielding says that you’re free to deploy state fulness, but then it is not REST as he defined it. While it is hard to disagree with that, it is beside the point. If REST is not willing to adopt it does not matter. Whatever we call it, we still need it.
So what is the practical solution? All REST resources are born and they die. Some live longer than others. And while you should strive for static resources as they are more useful, they are not the only resources that have a right to exist. Just as you already can add a user in your current REST system, implement a session in the same way. Keep it on the server just as you do with your users. Refer to it when doing your requests. However, reserve the URL for long lived resources. If your session will be valid for years (as is the case with a User session), its global identifier should live in the URL. These are issues that REST should address rather than ignore.
Other than that, the session is just another resource. And just as you would at some point want to clean up abandoned unused user accounts, do the same with abandoned sessions. For some use cases, the user is the session. The invalid URL is All resources have a life span. Your home page might live forever, your database objects for a long time. Some kinds of sessions live for weeks and some for seconds. Embrace it. The same goes for scope and accessibility. Your home page is visible for everyone while the user profile rights are restricted to few and the session data is rather private. Although sessions gives us performance headaches, they are nothing more than another resource.
And do not apologize for it.