Over the past few of years we have seen an increase in the volume of discussions around alternatives to traditional database technologies, often referred to as NoSQL. Whether it's at events such as the High Performance Transactions Workshop or here at InfoQ, it is getting almost as hard to ignore NoSQL as REST or SOA. Initial work appears to have been aimed at replacing the traditional RDBMS with NoSQL implementations, as discussed in 2009 and even earlier in 2007, when one of the original creators of Postgres and Ingres, Mike Stonebraker, predicted their demise. However, it was inevitable that as REST-based companies such as Twitter and Amazon became strong advocates of NoSQL, we would see the two technologies used together.
However, in a recent posting, Ganesh Prasad asks whether the advent of NoSQL requires us to re-evaluate one of the central aspects of REST. Ganesh believes that there are two aspects of REST that are signficant drawbacks to the approach:
One is its client/server model rather than a peer-to-peer model, which I think would have been more generic and useful. The second [...] is the insistence on statelessness (or alternatively forcing anything stateful to be either managed by the client or modelled as a resource).
It is the stateless aspect that he concentrates on in his posting. Now we have certainly heard a lot about state and REST over the years from other sources. For instance Bill Burke discussed this aspect several years ago:
In REST, stateless means that there is no client session data stored on the server. The server only records and manages the state of the resources it exposes. If there needs to be session specific data, it should be held and maintained by the client and transfered to the server with each request as needed. A service layer that does not have to maintain client sessions is a lot easier to scale as it has to do a lot less expensive replications in a clustered environment. Its a lot easier to scale up as all you have to do is add machines.
And Stefan Tilkov places REST and state firmly in context:
First of all, it’s important to stress that although REST includes the idea of statelessness, this does not mean that an application that exposes its functionally cannot have state — in fact, this would render the whole approach pretty useless in most scenarios. REST mandates that state be either turned into resource state, or kept on the client. In other words, a server should not have to retain some sort of communication state for any of the clients it communicates with beyond a single request. The most obvious reason for this is scalability — the number of clients interacting would seriously impact the server’s footprint if it had to keep client state. (Note that this usually requires some re-design — you can’t simply stick a URI to some session state and call it RESTful.) But there are other aspects that might be much more important: The statelessness constraint isolates the client against changes on the server as it is not dependent on talking to the same server in two consecutive requests. A client could receive a document containing links from the server, and while it does some processing, the server could be shut down, its hard disk could be ripped out and be replaced, the software could be updated and restarted — and if the client follows one of the links it has received from the server, it won’t notice.
However, although Ganesh understands why statelessness is a good thing from a scalability and recovery perspective, he still questions this aspect and believes that it pushes too much up into the application layer that should be dealt with within the distribution infrastructure:
This is an acceptable approach for application domain-specific elements, but there is also a domain-neutral class of session-stateful elements that are useful for providing qualities of service (such as message sequence numbers for reliability, or session keys for security). REST's refusal to support these within the protocol has cost it the ability to provide qualities of service in a uniform way [...] So qualities of service end up becoming an application responsibility in REST, which has always struck me as a bit of a cop-out on the part of the protocol.
But it is the type of state that Bill and Stefan refer to in their articles to which Ganesh turns his attention: session state. According to the article, NoSQL offers a scalable and fault tolerant solution to this problem. Although Ganesh refers to the Redis implementation, presumably most (all?) NoSQL implementations would suffice too:
It's now becoming recommended best practice to store session state in a NoSQL database like Redis rather than in memory. Delegating session storage is an alternative to session-aware clusters, since the servers can now be a simpler stateless farm and access the NoSQL database for shared session state. What's impressive about Redis is that the complexity of its GET and SET operations is of Order(1), i.e., constant time. This means that (in theory at least) one can increase the number of servers using a Redis datastore indefinitely with no impact on performance.
The article goes on to describe how a Redis (NoSQL) datastore could be used to manage session context state in a way that Ganesh believes means that stateful REST applications should now be a serious consideration, (and presumably requiring an update to the REST principles perhaps through an enhancement?) He concludes with:
It would be good if a standard and application domain-agnostic mechanism could be evolved to provide security and reliability to REST-based interactions, using [NoSQL] scalable session storage.
Most of the successful software development methodologies, frameworks and standards have maintained their relevance by evolving as new approaches and experiences are obtained. NoSQL was not even an academic exercise when REST was first proposed, let alone a series of implementations used in various industrial settings, so it does raise the question: does REST need to evolve because of NoSQL or is statelessness a requirement irrespective of the approaches that can be used to implement and store state?
