There's an article over at XML.com in which the author contends that Google's recent roll-out of a SOAP-based API is a bad thing, described as "one step forward, two steps back". The basis for this contention seems to be the emerging REST (REpresentational State Transfer) approach, the basis for Amazon's web service interface. But I'm not really buying the argument, and not because of lack of familiarity with REST.
My reservations are that the arguments seem to revolve around whether the GET or POST HTTP verbs are the way to go. More specifically, the argument seems to focus on whether the same sort of functionality can be accomplished without the overhead of a full-on SOAP envelope. This is not an empty argument. Matts, in a recent journal entry, made a very valid complaint: Google had, before the much-trumpeted SOAP roll-out, already provided an XML searching interface. This interface is fully-accessible from a GET URL, so it would seem (from first glance) that moving to a SOAP envelope is excessive. Perhaps in this specific case, it is.
The problem is, I can't help feeling that to embrace this is to completely ignore the future potential that a fuller SOAP interface could offer. True, there are layers to be had in the REST specification that I have not yet read. But that isn't the problem. The problem is that arguments are being based (it seems) on the fact that current applications based on SOAP are pretty much XML-RPC-based applications with greater verbosity in the wire protocol. But that is the current crop of applications, and that crop is just the beginning. It's no more valid to judge SOAP on the merits of these applications than it is to judge Perl on the first generations of scripts written for the earlier versions of the language.
Web services are still relatively young, even in Internet-years. Google's
API is more than just a new level of convenience (if even that), it's a sign
of corporate-level acceptance and embracing of the concepts behind web
services. Without these kinds of moves, the only thing we're likely to see are
those that are directly cooked up by monopolistic entities whose intent is to
corral the future direction of information exchange and route it through their
I think the mistake that is being consistently made is assuming that all SOAP applications will always be based on an RPC model. There's no way to know that for certain. The WSDL specification allows for identifying a service as having a document-oriented nature as opposed to a rpc-oriented one. I haven't seen any document-oriented services yet, but I expect to. I think proclaiming SOAP as obsolete is vastly premature, just as it would be to make such a claim about RPC in general (or XML-RPC in particular). When Java was first introduced, it was scrambling for a viable niche in the field of programming languages. While some would argue with me on this, I think it's started to find its place with applications such as ArgoUML and StarOffice. And that is what I think the arguments over SOAP vs. REST and all the other RPC models boil down to: what niche is there to be filled, and how many solutions can be fit into it?
Java found a place without displacing any other languages. Maybe REST can find a place without having to displace SOAP in the process.
The problem with defending the purity of the English language is that English is about as pure as a cribhouse whore. We don't just borrow words; on occasion, English has pursued other languages down alleyways to beat them unconscious and rifle their pockets for new vocabulary. -- James D. Nicoll