BT

Does NoSQL have an impact on REST?

by Mark Little on Oct 16, 2011 |

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?

Hello stranger!

You need to Register an InfoQ account or 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

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Authentication - REST in practice always had sessions by Adam Nemeth

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)

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

Adam, could it be that you have no idea whatsoever what you are talking about?

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

Mark,

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

Hi.
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

how about...
"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

Hi Mike,

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

Hi Mark.
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

William:

"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

Albiet a sensational title for a news item :) ... If I may speak for Mark, news items dont represent opinions. Its a way to get the news out about interesting articles, to get the community involved. So dont shoot the messenger!

Re: srsly? by Dilip Krishnan

William, actually Amazon had one of the first restful API's in the wild... i.e. S3 api. I havent seen it in a while, but I suspect it shouldnt have changed.

Re: srsly? by Mark Little

Yes, we could argue about the title though I don't think it *that* sensational. However, the aim of the article was definitely to bring the discussion into the mainstream since this (state and REST) is something various people have spoken about for years and maybe NoSQL has something new to offer. As a scientific community we should be willing to evaluate new facts as they come to light. My personal opinion is that NoSQL doesn't impact REST principles.

What REST? by Rickard Öberg

As others have already "hinted" at, a BIG problem is that just what "REST" means is widely misunderstood, and I have feeling largely because blog/article authors have not read the thesis, but only read what other blog/article authors write about what REST is. Which is 99% of the times wrong. The main thing I see missing everywhere is the hypermedia constraint, and as Roy says, yes it IS a constraint! If the client is not driven by links, and availability or absence thereof, it aint REST. It took me quite a bit to "get" that part, but once I did, it was the biggest "duh" moment of my life. And once you get it, and use it, it really really helps. BUT, once you get what the hypermedia constraint is there for, and how it helps, it makes pretty much little to no sense why a database would want to be REST at all. The constraints in REST are best used (IMO) between distributed clients and server applications, where there is a likelihood that they will evolve independently. That just doesn't happen in the database case, so those constraints don't really help. So... don't use that architectural style. You can use something else that is HTTP-based, maybe, but probably not REST and hypermedia. Just do like CouchDB and MongoDB and build a HTTP API, and be done with it. But don't call it "REST", cause it just isn't if you don't follow the constraints.

Re: srsly? by Rickard Öberg

The S3 API is not a REST API, simply because it does not follow the hypermedia constraint. It's a HTTP API, or "Web API", or whatever you want to call it. And probably just fine like that. But REST it isn't, even though it pretends to be.

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

In an attempt to ensure that the debate doesn't centre around the title of this article, I've made a modification that I am happy with. I've also addressed your disappointment in the article, which was actually already in there but not called out much.

Re: What REST? by Jan Algermissen

Rickard--
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

Oh and the Twitter API is also not a REST API, as it does not follow the hypermedia constraint. It's a "Web API", or whatever you want to call it.

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

Dilip, there is no "my definition", or "your definition", or "Bills definition", there is only "the thesis definition" (specifically, www.ics.uci.edu/~fielding/pubs/dissertation/res...). And no, what S3 provides is not hypermedia, as there are no links to select from, and hence it does not comply with the hypermedia constraint. It is very very simple. The S3 API is a "Web API", if you want to call it that, but it just simply does not follow the REST constraints, and is therefore not RESTful. Read the thesis, if you haven't already.

Re: srsly? by Jean-Jacques Dubray

Rickard,

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

JJ,

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?

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

23 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT