Does NoSQL have an impact on REST?
- Share
-
- |
Read later
My Reading List
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?
Authentication - REST in practice always had sessions
by
Adam Nemeth
OAuth, in fact, is a kind of permanently stored session.
But if you look at it, it's not only that: while GET works well to read out states, in nearly all other practical use cases, popular REST fails to solve anything. If you look at all the favourite APIs out there, you'll recognize it's rather URL-RPC (sending call parameters in query string, headers, or body), than REST.
Perhaps we should start to accept it and build on this as a foundation rather than continuing to pretend REST principles are practical - they are not.
Re: Authentication - REST in practice always had sessions
by
Jan Algermissen
Show me any use case that requires authentication and I show you how to do it with HTTP. Statelessley and secure.
Sure credentials are some for of state - they are just not *application state* so your point does not really apply here.
And hey - the fact that APIs out there are favorite does not mean they are well designed.
Evolving REST to be stateful
by
Jan Algermissen
why don't you go ahead and show what system properties an architectural style can guarantee that is "REST - 'stateless-server-constraint' + 'stateful-server-constraint'"? The dissertation provides a good blueprint for doing that - you could start with altering the derivation lattice at www.ics.uci.edu/~fielding/pubs/dissertation/res... by replacing CSS (client server stateless) with CSSF (client server statefull). Following Roy's deduction path you could answer your question "does REST need to evolve" by showing what set of problems are better solved with the new resulting architectural style.
Need to understand first, propose later.
by
William Martinez
Just to clarify:
1. There is a subtle difference in the use of state, for whatever we are talking about. REST requires scalability in a networked application (which means lots of communication), and since it is using communication between client and server, we need that communication to be quick and detached (or even non-existent). One option (the one chosen by REST) is to have stateless communication. It does not say NO STATE AT ALL. It just say, keep away from communication that requires storing the state OF COMMUNICATION in one server in a way that binds one client to that one server during the complete application's life.
2. To use something different for the sake of the application, is totally normal. REST is not suitable for all applications that run on the web. If you need to use something different, great. That does not mean you need to change REST to make your application keep the "RESTFull" trademark. That is a nonsense. IN other words, if someone finds a way to achieve all the quality properties REST is aiming at, and that is using different restrictions, great, name it whatever you want, it is not REST, and we do not need to "evolve" REST to match it. We then have TWO different styles that achieve same quality properties (or similar ones) and let the architect choose.
3. If we require statefull communication and no scalability, fine, do not use REST. I feel that is my most important point, instead of going into discussing how can we make REST do what it was not designed to do to achieve properties it is not destined to achieve.
Cheers!
William
srsly?
by
Mike Amundsen
"Does NoSQL require a re-evaluation of state-less network protocols?"
"Does NoSQL require a re-evaluation of Pipe-and-Filter"?
"Does NoSQL require a re-evaluation of Event-Based Integration models?"
"Does changing the data-storage model invalidate a network architecture?"
possibly, while reading through the above list of alternate headlines, you might think that i've incorrectly pitted unrelated items against each other; possibly attempted to create a false equivalence. you'd be right. headlines such as these often do.
and, srsly - "re-evaluation"? c'mon! let's just replace that word with "invalidation", "abandonment", etc.
oh, and "REST-based companies such as Twitter and Amazon"? [sigh]
I'll deal with Ganesh directly.
Re: srsly?
by
William Martinez
This is the first time I read something ironic from you. Very well said!
Now, the subliminal comment about Twitter and Amazon... Yes, probably that is why we have mistakenly understood REST, when we think it to be just like the APIs those guys are publishing. And then all makes sense.
Cheers.
Sorry, My Answer.
by
William Martinez
Sorry,I didn't answer you question: NO, REST does not need to evolve. We need to understand REST in order to select it and use it as it should. And we need to stop trying to use it for whatever we need in the terms that we need.
Regards.
Re: srsly?
by
Mike Amundsen
"ironic" is proly being generous. maybe "sarcastic" is better? :)
my remarks proly do not she much light on the topic; a laziness on my part today.
anyway, yes "REST" continues to be used to describe a wide and conflicting range of ideas. as long this this continues (and folks are not careful when they invoke the term) misunderstandings via false assumption will continue.
my general POV here is that REST is not science (not a theory), but engineering (a style, a methodology). Scientific theories are expected to be falsified at some point and _replaced_ by a theory that better describes the real world ("Sorry, Mr. Copernicus, ol' pal planets do not orbit in perfect circles"). Engineering methods may be surpassed at some day ("We now have the materials and tooling to build ever longer bridges") but these advances do not "weaken" or "negate" the previous accomplishments ("All the old bridges built of simple stone are still standing today).
Ganesh may be trying to make a case for a _new_ style based on advances in engineering (materials, tools, techniques) and i think that's good. But, while advances may render old methodologies "passe", it does not render existing implementations "invalid."
i was disappointed that Mark did not address this particular aspect of Ganesh' post.
i'll follow up with Ganesh directly on this.
Re: srsly?
by
Dilip Krishnan
Re: srsly?
by
Dilip Krishnan
Re: srsly?
by
Mark Little
What REST?
by
Rickard Öberg
Re: srsly?
by
Rickard Öberg
Here's a generic test of whether a REST API is a REST API or not: go to the entry URL with a web browser. Now check, can you perform all operations by simply following links and submitting forms. If yes, it's most likely a REST API. If not (e.g. CouchDB), then it's not a REST API.
Re: srsly?
by
Mark Little
Re: What REST?
by
Jan Algermissen
spot on! Thanks for that - we need many more clear voices like yours! The amount of dis-information around REST is increasing at an alarming rate now that it is a hype.
Re: Authentication - REST in practice always had sessions
by
Luis Espinal
While it's a nice theory to have no sessions, in over 90% of cases, we're required to manage access rights. In order to do so, we must employ sessions in order to solve certain security issues (like, repeated transmission of password can lead to easier security breach)
This has been solved many times ago by replacing passwords with authentication tokens, capabilities, client-side credentials and what not, the transfer of which done over HTTPS or some other mechanism robust enough against man-in-themiddle/replay attacks. You do not need application session persistence to deal with the type of problems you are discussing. I think you should get acquainted with the field of computer security. Just saying.
OAuth, in fact, is a kind of permanently stored session.
OAuth is for authorization (discretionary to the user), not for authentication. Not sure what this comment is for.
But if you look at it, it's not only that: while GET works well to read out states, in nearly all other practical use cases, popular REST fails to solve anything.
Citations please. I mean, I don't think REST is a silver bullet, but what you just said right there is a very strong statement, one which demands some evidence to back it up.
If you look at all the favourite APIs out there, you'll recognize it's rather URL-RPC (sending call parameters in query string, headers, or body), than REST.
1. Examples please.
2. Proof that what you are describing is evidence that REST is unsuitable, as opposed to being an evidence of APIs not properly implementing (or strategically choosing not to implement) REST.
3. Proof that REST is successfull only if it is implemented 100% to the letter, independent of strategic decisions (see above.)
Perhaps we should start to accept it and build on this as a foundation rather than continuing to pretend REST principles are practical - they are not.
Perhaps you should quantify and qualify your statements. Just saying. I mean, seriously, your statement is completely falsifiable since there are applications out there (for internal and external usage) that use REST successfully.
There are context-specific issues with REST that need to be addressed. You are doing a poor job at it, though.
Re: srsly?
by
Rickard Öberg
Basically, if I say "the sky is purple", does not necessarily make it purple, even though I said it was. Similarly, an API is not "RESTful" if I say it is, just because I say it is. It becomes RESTful if it follows the constraints set out in that particular architectural style.
Re: srsly?
by
Dilip Krishnan
The S3 API is not a REST API, simply because it does not follow the hypermedia constraint.
That is not a true statement on multiple levels... Firstly it does implement a form of hypermedia; though not the conventional "form". Secondly, while it might not achieve the Glory of REST according to your definition, it doesnt violate any of the RESTful principles at least to my knowledge.
Re: srsly?
by
Rickard Öberg
Re: srsly?
by
Jean-Jacques Dubray
I think you are wasting your time. There is a number of people who can't care less about what REST is, everything HTTP is RESTful to them, and it of course solves every problem known to an architect or a developer. Even Roy told them they were wrong, but that is not going to stop them.
JJ-
Re: srsly?
by
Dilip Krishnan
Even Roy told them they were wrong, but that is not going to stop them.
lol! By that, I hope yr not clubbing me with those folks! :)
Re: srsly?
by
Jean-Jacques Dubray
It's not for me to say, basically everyone should decide whether they adhere to this statement from Roy or not:
- A REST API should be entered with no prior knowledge beyond the initial URI (bookmark) and set of standardized media types that are appropriate for the intended audience (i.e., expected to be understood by any client that might use the API).
- A REST API should never have “typed” resources that are significant to the client. ... The only types that are significant to a client are the current representation’s media type and standardized relation names.
- A REST API must not define fixed resource names or hierarchies (an obvious coupling of client and server). Servers must have the freedom to control their own namespace.
My understanding is that Rickard does. Do you?
Re: srsly?
by
Ganesh Prasad
You've been anti-REST if I recall (you consider it to be a form of distributed objects, and you think it couples identity and access in a terrible way - your words). Is the above post from you a case of the devil quoting the bible or have you genuinely acquired an appreciation of REST?
Educational Content
.jpg)
Managing Build Jobs for Continuous Delivery
Martin Peston May 24, 2013
Clojure in the Field
Stuart Halloway May 23, 2013
Tuning the Size of Your Thread Pool
Kirk Pepperdine May 23, 2013
Hello stranger!
You need to Register an InfoQ account or Login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think