REST Web Services and Superstition
It’s been forever since I write anything. My plans for writing haven’t changed; I’ve just been swamped at work, sick, and a few other things all at once.
For now, let’s play a game called “tell me why I’m wrong.” My argument: RESTful web services are often hyped, and only occasionally beneficial.
I do admire this: the “REST web services” marketing has been phenomenal. Wow! This is one of the great success stories of rhetoric. Web services meant something in the very early days. By proclaiming loudly and often that SOAP and REST are alternative types of web services, it was possible to get acknowledgement of REST every single time someone talks about web services, at the risk of being “corrected.” Never mind that the whole “the web itself is a REST service” nonsense belies that the term has now been stripped of any meaning; millions of people will assume someone’s stupid if that person doesn’t play along with taking “REST web services” seriously. It’s a nice play on the human dislike for being thought wrong.
Now, the reasons to prefer non-REST web services (i.e., the original kind, for which the phrase was invented) are clear. Basically, it comes down to this: average programmers don’t have have to do anything. Marshalling, networking, and everything is handled in a library that exposes an interface – on both sides of the connection – exactly analogous to the set of things someone will actually want to do.
Now, it seems, I should make my web services more RESTful. There really seems to be only one reason, and it amounts to setting up “the web” as an ideal to strive for, and then pointing out that SOAP-based services don’t meet that ideal. Of course they don’t; that was never the right goal to begin with. If I’m writing software for foo, I ought to be concerned with whether my remote interface is consistent with the goals and ideals of foo, rather than the web. When providing any kind of remote interface to some piece of functionality, the goal should be to accurately represent that functionality. No one cares about the transport protocol.
Perhaps we could build techniques for abstraction that make REST web services as easy as SOAP. Great idea, and WADL tries to do it. But oops, Joe Gregorio says that’s not good. Of course, Joe is not alone. It seems he’s part of a massive movement of people scrambling to block this approach. The technique is similar: it’s not “RESTful” enough; in other words, too little like the web. Apparently, abstraction is not web-like enough, so we should drop it.
Yes, “the web” has been successful. It’s been successful because it fulfilled a need, and made choices that were the right ones for its problems and challenges. When faced with different challenges, other decisions are the right ones. Leonard Richardson (author of the popular book RESTful web services) admits in an interview with InfoQ that many more dynamic web applications (those that solve problems different from the web) don’t follow REST principles at all. Of course, he follows that with a comment that the web would just be better if they did; but with no justification. These are people who solved different problems, and they used different ideas to do it.
So I view REST as a superstition; the web is great, and it does these things, so we should to. Jedediah died, and he walked under a ladder, so we shouldn’t walk under ladders. Is it all the same glitch in the human psyche?
Sententia cdsmithus 
I agree. I think the main argument for RESTful style is that, if you’re a Rails developer, it makes the programming a little nicer. Of course, it demands that you do things in a much different way, and it requires some hacks to make it happen. After all, the REST rhetoric sweeps the whole issue of browsers never sending DELETE and PUT requests under the carpet, so even in Rails using REST, there are kooky things happening under the service to make things seem cleaner than they really are (the _method hidden variable, namely).
On the other hand, I can make an argument for REST being a nice ideal, and I have a lot of trouble making that same argument about SOAP, especially in a universe that already has the Ice protocol (http://www.zeroc.com).
One of the neat things about REST is that it makes it easy to examine and debug your web service armed with little more than a text editor and a HTTP client.
If you need plain RPC, then stay with SOAP, CORBA etc.
It’s a bit funny that someone interested in Haskell
is that negative about REST. With REST, GET and PUT
are like pure functions. You will always get the same
result, irrespective of how often you call them
with the same parameters.
With REST, simple web caches can help you with performance
problems. GET/PUT can be ‘memoized’.
The ‘function call’ or ‘method call’ model XMLRPC/SOAP is
neither the only nor the best abstraction for web services.
Take one example — I use web services very little, but I suspect this example might be typical: http://www.gnpcb.org/esv/share/services/api/ .
For the REST API, there are no reported difficulties. It’s extremely easy to use from Python code, and requires nothing but standard libraries. The SOAP version is considered experimental as it has only been tested with a couple of frameworks. But why do you even need to test with more than one framework? The answer is found here:
http://wanderingbarque.com/nonintersecting/2006/11/15/the-s-stands-for-simple/
It’s the mark of an elegant protocol to see it extended usefully, so I’m not begrudging the fact that REST is actually putting two neglected HTTP verbs to use. What does drive me nuts is the claim of its proponents that theirs is The True Way, that HTTP was designed with this way in mind. Aside from the annoyance factor of this brand of evangalism, the facts of history differ.
I remember HTML 1.0, I remember HTTP/0.9 and regardless of TBL’s elegant design (that never really saw realization even in HTTP/1.0), it wasn’t an application protocol then, and isn’t one now. It was designed to link documents — and only HTML documents to start! It wasn’t until HTTP/1.0 that it grew to support MIME, which solidified the document focus even more. PUT was designed to place a document at a URL, and yes, that has idempotent semantics, but all the frantic handwaving about “four verbs” doesn’t remove the fact that it’s about as multi-purpose as the PUT command in FTP.
In general, it matches my experience and others elsewhere that SOAP is insufficiently standardized to act as a reliable form of communication.
I would say, in response to some of the other comments, that REST assumes a higher burden by presenting itself as an ideal in the first place. That is, everyone understands that technologies to have flaws; but REST isn’t a technology. It’s only contribution is to establish an ideal.
From where I’m sitting, judging by this standard, REST sets up a limited ideal. It works for many simple applications. It seems to work reasonably well when the application has to with publishing stuff. Big success stories for REST include the Atom Publishing Protocol and S3 (which is essentially a form of publishing). This is no surprise; HTTP was designed for that sort of thing, and REST being a generalization of HTTP extends well to it.
Where things get murky is when the exaggerated claims start flying: things like, the web would be better if all web applications were more RESTful. Such claims require great evidence, which to date is somewhat lacking.
“I do admire this: the “REST web services” marketing has been phenomenal.”
By what standard? People have been strongly advocating this for *years* and it is only now beginning to see the light of day. The rest-discuss group began in 2002 and some of the seminal articles/postings etc are older than that.
This isn’t an example of hype, but of the best approach rising to the top in pure Darwinian competition.
I suspect that you don’t have a good picture of what REST means. That’s not meant to be a dig or insult, and it’s totally understandable: Lots of current web services call themselves REST when they’re not at all. In fact, there really aren’t that many actual REST-style services around yet.
Making a service RESTful and following the patterns of the web is not superstitious – there are definable and enumerable benefits. When you can constrain things down to a handful of verbs across the web, you can do interesting and reusable things for every service on the web.
An example: Caching. If you know GET does certain things, no matter what the particular resource URL is, you can work at a higher level. Knowing that GET is idempotent and how conditional GET headers work, you can implement caching for any RESTful service.
For RPC services, there are very few things common between services. You couldn’t do something like caching for every RPC service, because most have invented their own snowflake-unique rules. Sometimes this is necessary, but far less often than is done. The rules of the web as-is fit a surprising range of scenarios.
For HTTP, there are pages and pages of RFCs on caching; error conditions; how to tell when a document has been modified out from under you; etc etc. If you can make your service conform to the rules of HTTP, you get the benefit of all this other work done on it and continuing to be done with it.
“In fact, there really aren’t that many actual REST-style services around yet.”
Actually… what I meant by that was, there aren’t that many *read/write* REST-style services around yet. Syndication feeds (RSS and Atom) represent probably the biggest read-only service, but generally look to simple to be thought of as a *service* per se.
I notice you use caching as an example benefit for REST. That’s not surprising, because in fact that’s the only example anyone ever uses. If I say I don’t need caching (which I don’t; I’d estimate that less than 20% of software actually does), what else is left? I can’t think of anything. Can anyone else think of anything? I can certainly think of advantages (plenty of them) for not doing dumb stuff like exposing mutation methods via GET. That’s not necessarily RESTful, though; it’s just un-dumb.
I suspect my issue is less that I have a bad picture of what REST means, and more that the REST movement is actively hostile toward abstraction.
Apart from caching, REST can use nice HTTP
features like the ETag/If-match headers to
detect simultaneous access to a single
resource.
As SOAP expects very little from its
underlying protocol, it has to duplicate
all the functionality already available in
HTTP. Not elegant.