subbu.org

Recently, there have been a number of blog posts and articles on this topic, and this time around, the REST side is winning, and I find two reasons for this shift. Firstly, HTTP is more ubiquitous than ever. Secondly, WS-* has reached a point where the complexity of specifications and related abstractions overtook the basics. This recent shift reminds me of the history of CORBA, and how it had its glory and then quickly lost it.

Looking at WSDL, SOAP, and related base WS specifications, the basic problem they try to solve is to keep the interfaces and messages independent of how messages are transported from one point to another. This kind of transport agnosticism is set in stone in some of the base specs. Most implementors of web services followed suite, and architected the core runtime such that “transport” is a last minute detail that can be changed at will without changing the semantics of application. Given that the goal is to keep the application independent of the transport, some of the basic ideas in SOAP and WSDL are not unnatural, although that does not excuse the proponents from the complexity and unparsable language introduced in some of the specs.

The trouble is that, the folks who designed WS standards and implementations solely for transport agnostic scenarios ended up selling the technology as a means to build loosely coupled distributed applications. With that, folks came up with explanations for why SOAP has headers, why SOAP needs additional security specifications, why you need special purpose web service proxies, and so on. This silliness went to the extent that some folks started circulating FUD that you can’t get the right “ilities” with REST. This kind of pitch works as long as the majority of applications are talking to each other over diverse transports, but that is not the reality today.

The reality is that, HTTP is more predominant today than ever. When the transport is HTTP, it makes more sense to design the interface to take advantage of the transport to the extent possible, and not try to hide the transport. With this approach, there is no need to bend over backwards and invent crazy specifications for things that could be solved very simply with HTTP. I find that this a bigger reason for the recent shift towards REST over WS. This shift may have less to do with the core principles of REST.

This change is somewhat similar to what happened to CORBA. When CORBA was designed, it was meant to solve a similar problem - i.e. to keep applications written in heterogeneous languages talk to each other. But then, it was sold as a general purpose distributed object technology, and ended up becoming uber-complex, but complexity can not be sold for ever. That is precisely what is happening to WS today.