On the death of SOAP

In a series of posts, Carlos Peres declares SOAP comatose, but not officially dead and then adds a few nails to the coffin. Says Carlos:

Today, half a year since my prediction of the rise of REST and the fall of SOAP, denial has been now replaced with panic. The RESTful approach has now born fruit. Applications like BlogLines, Flickr, Mappr, Del.icio.us and 43Things are revealing that proof is in the pudding. All of these have shunned SOAP in favor of more RESTful designs. In stark contrast, the SOAP high priests have nothing to show but fancy visual tools. Their followers are at the brink of rebellion and if they don't act quickly they could find themselves swinging from a high treetop.

Carlos quotes a number of blog entries in support of his thesis, but perhaps the most important point is this. After discussing some Web services interoperability tips given in a talk by Simon Guest, he moves in for the kill:

Of course, the last 2 tips are the most revealing of all. If everything is sent over the wire as a XML document that is described by an XSD then it all boils down to how easy you can work with these documents. That is working with XML api's like DOM and XPath. The enclosing envelope should be irrelevant to the concerns of the average developer; it should be treated like just any other transport protocol. All that extra machinery provided to support the SOAP envelope is precisely that, extra machinery and has never been shown to improve interoperability. Therefore, in terms of effort, interoperability via SOAP is not any easier than doing it in REST. In fact, its actually more insidious because a developer is all too easily lulled in the fallacy that an object is the same as the XML document.

This is a powerful argument. In his talk last week at ETech, Nelson Minar of Google made similar points, without necessarily stating the same conclusions. Google's new AdWords API uses the SOAP document model and its clearly documented with XSD, reinforcing Simon's interoperability tips. Interestingly, some of the interoperability problems Nelson had with various languages would go away if SOAP were not in the picture and developers just dealt with the XML documents using some other transport.

Nelson did discuss the use of REST. If you read his list of limitations, for REST, you'll see things like a lack of support for standard fault mechanisms, no data binding tools, and so on. In short, he's saying that vendors haven't put as much time and energy into building that scaffolding around REST as they have for SOAP.

Being familiar with the corporate IT mindset, I think that's a serious limitation. Corporate IT is based around tools, frameworks, and products from vendors. IT shops tend to be deep in integration and operations expertise and shallow in hard-core programming expertise. This partly is a response by CIOs to the unpredictability of in-house programming projects. Don't forget how unusual the examples that Carlos cites are in the larger world of corporate IT.

The challenge for the RESTful crowd is to create a well-thought out transport alternative to SOAP. HTTP is the basis for that transport, but it's not enough. The place to start is with service description and data binding so that RESTful Web services can enjoy the same kind of discovery that possible with SOAP. Paul Prescod made a start with his WRDL proposal, but it hasn't really taken off.