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
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
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.