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?