Tuesday, 13 May 2008
How REST will neuter Web Services
« RESTful Service Descriptions | Main | What is Loose Coupling? »
I normally like to blog about things that are, and leave tea leave reading to others. Not today. I've been thinking more about a specific example of solving a problem in the RESTful way, and the solution seems like one that is likely to play out in many different arenas. So here's my attempt to predict the what will happen as RESTful thinking penetrates into some of the harder aspects of software engineerings...
Basically, I think REST is going to neuter web services. Not destroy - just neuter. Instead, the Great Irony is that as RESTful patterns for solving problems of enterprise development are discovered, used, and socialized, the net effect will be to unleash a great revival of custom, not-HTTP, non-RESTful protocols. What!?! you say. Read on.
The particular problem I referred to above is a basic one in event driven architectures. The problem statement is this: How do you create a channel for messages where messages are queued, but consumers have unique ownership of messages they dequeue. This is basically the asynchronous form of a message based load balancer, used to drive (among many other things) highly horizontally scalable "master/worker" solutions. James Strachan has a RESTful solution to the queue problem. I've studied it. I recommend you study it, and read the thread at rest-discuss.
This blog is not about the solution per se, but more about who's looking for such solutions, and what they are going to do with them. ActiveMQ is a framework that created a use case specific protocol (Openwire) for messaging that works really well. They want to add RESTful HTTP to their stack of messaging protocols, which also includes STOMP and XMPP, and hopefully one day soon, AMQP. It makes a lot of sense why they would want to enable HTTP as a transport for messaging, but notice that the effect is to make it easier to use ActiveMQ, which is inevitably going to get Openwire solutions in place, for one simple reason: IT'S A LOT BETTER AT MESSAGING.
There's a really excellent comment in the rest-discuss thread about REST, compared to custom protocols, by Alan Dean. He's just collecting comments from Roy Fielding. The first notes that REST's statelessness requirement involves a tradeoff against custom protocols that may degrade performance, since custom protocols can reduce networking costs by leaving data on the server. The third quote notes that abiding by the uniform interface also involves a tradeoff because generic interface methods generally won't be as efficient as those tailored to a specific problem.
Now think of all those WS-* specs out there. Each one was somebody trying to solve a problem that comes up in complex systems. Instead of having another REST vs SOAP debate, how about a different question: why web services at all? Why NOT problem specific protocols like Openwire or AMQP? The standard answer is that these involve sacrifices in interoperability. Unless clients also speak Openwire, they can't get your information. While many clients may choose to do so, those that don't are excluded. This is not good.
But this is why REST is so appealing. It's the ultimate least common denominator solution. EVERYBODY speaks HTTP. It's even really good at some things, if you use it in the RESTful way. And if you leverage "hypermedia as the engine of application state" and idempotency, even hard things are possible (like building concurrency safe queues). But look at WHO is going to solve the hard problems. It's going to be custom protocol creators who are trying to overcome the interoperability objection to their "best" solution. It's guys like James Strachan who want to get ActiveMQ out there for messaging. Instead of a bunch of WS-* goop, REST will see its solutions come more as solution patterns that interact with a specific implementation toolkit that solves the problem for you. These implementations will also have custom protocols tailored to the problem. I predict most people will use these, secure in the knowledge that somebody who can't speak the language can always drop down to the super-portable RESTful API.
In fact, if you use languages that have good client libraries, why wouldn't you use Openwire over REST for it? Especially when the framework provider is going to hand you juicy client libraries to go with server binaries that "just work". The guys who have to use the RESTful mechanisms are the ones that write in languages that don't get big communities creating client libraries for every protocol under the sun. Your Erlang, Lua, or whatever client may have to interact via RESTful HTTP with the server. System admins and monitoring systems will poke at production servers to make sure they're alive using the RESTful APIs. Generic things will be done via REST.
So this is why I say REST will neuter web services. The super accessibility REST provides (better than SOAP solutions) is one half of a tradeoff. The other side is solving the problem with a highly tailored protocol solution that performs and scales. Folks that want the latter will bundle the former with it as a hedge. The end result, I predict, will be that more problems will be solved using tailored solutions which previously would have been unpalatable because they aren't universally accessible. SOAP won't beat either solution, but it won't lose to REST, it will lose to custom protocols that aren't truly viable until they add a RESTful interoperability API.
Posted by at 1:24 AM in the internet, web, web 2.0 and beyond
[Trackback URL for this entry]
How REST will neuter Web Services
a Wordpress blog? Make monetization easier with the WP Affiliate Pro plugin. How REST will neuter Web Services saved by 5