SOAP Wars

by Marc Hedlund

Related link: http://www.xml.com/pub/a/2002/04/24/google.html



Two of the front-page O'Reilly Network articles today take different views of SOAP: Paul Prescod seems to be trying to "prove" that SOAP was the wrong choice for the Google APIs, while Clay Shirky lauds SOAP as "astonishingly far along." I'll further this diversity of viewpoints by throwing in another two cents.



I should disclose that I am good friends with one of the Google engineers who worked on the APIs, and I'm sure this biases my viewpoint. I'd also say, though, that I fundamentally disagree with Paul's viewpoint that Google made a "gaffe" by choosing SOAP -- even if he has another technology he'd prefer, the SOAP API (which I beta-tested before it was released) works, and works very well for developers who want to experiment with Web services. Google could have chosen another platform, but with so few real Web services available, I am very supportive of their decision to use the most widely-accepted standard for providing such services in their first release. How many lines of XML go in and out (or how much energy is consumed, as Paul facetiously -- I hope! -- points out) should not be the only criteria for which technology Google chooses.



Speaking as a developer, I currently don't have any reason to care one way or another which path Google takes. Submitting a SOAP query is easy to do, and there have been plenty of Google API toolkits released in the week or two after the APIs became available. Sending a specially-formed URL with arguments wouldn't really need a toolkit, but I bet toolkits would appear, and I'd use them, too. So the only developers who should really care right now are: (1) toolkit developers, and (2) speed freaks. (1) seems to be not an issue -- it
can't be that much harder if so many SOAP toolkits appeared in a week -- and with 1000/queries/day maximum per user, (2) speed freaks need not apply.



Speaking as a technologist, I think the demand for REST in this case is driven more by aesthetics than practicality. Maybe it's really just anti-Microsoft. It feels like bloat, so people are opposed to it. For myself I like all of the things Microsoft has built on top of SOAP (like
auto-generated docs and so on), and I could easily conceive
of other people or companies building other cool things on top of it, too. If there's a bunch of "foo for SOAP" that I can use, great, that makes my job easier. I would speculatively feel more enthusiastic about releasing a Web service that could play well with foo for SOAP, rather
than one that hews to a notion of aesthetics but doesn't support foo.



Speaking as a product manager-type, I would say Google should support the "platforms" with sufficient business demand. View SOAP as Windows and REST as Linux and XML-RPC as Mac and make decisions accordingly. Do they have a business that would justify spending money to develop for multiple platforms based on the possible return from those platforms? Then maintain multiple interfaces. No? Then stick with the platform with the widest adoption (which I am assuming is SOAP). Really this argument is somewhat specious since the platform adoption rates are nowhere near as clear as they are for OS's. It's more like you have three BeOS's duking it out for platform dominance no one cares about yet (the fights are so fierce because the stakes are so low). Given that, I would just choose the one you like (as in, "would bet on if it were a
horse") and experiment with it on its own until there is better data for business analysis.



Taking the three of these considerations in combination, I would say that there's no point in a business like Google investing in more than one Web services interface until there's money attached to use of the service; and all other things being equal, which they seem to be, I would bet on Microsoft (i.e. SOAP).



So, I agree neither with Paul nor Clay. We don't yet know which technologies are going to make it in the Web services world; there are several considerations that might go into the outcome; and unless more businesses follow Google's lead and release Web services of their own, this discussion simply won't matter. If Amazon and Google use two different design models for their services, that's excellent -- it allows us to see how their respective services develop over time. Maybe one of these technologies will be more flexible, or will perform better, or will be easier to use, or will otherwise attract more development. Just like the O'Reilly Network is willing to give equal time to several viewpoints on this debate, we should be happy to have a variety of Web services approaches represented in the marketplace.


5 Comments

Edd Dumbill
2002-04-25 02:23:51
Why you should care
You write that as a developer you have no reason to care about using SOAP or not. I discuss the reason why you should care in my recent XML.com editorial. In short, I don't believe "it works, so it must be OK" is a valid justification. It doesn't seem to take anything but the most shortsighted view.
precipice
2002-04-25 10:09:54
Why you should care
I think your editorial is interesting and well worth reading. I certainly agree that the development of standards -- including the way these standards are chosen and evolved -- is critically important. I don't think, though, that the average developer trying to get work done engages at that level of debate; standards wars are usually more for the technologists (in this case, the people who write and implement standards, and the companies that try to adopt them). If you're a developer trying out Web services for the first time, SOAP will work just fine for you -- as you say yourself at the beginning of your article.
paulprescod
2002-04-25 10:53:11
Please re-read
"So the only developers who should really care right now are: (1) toolkit developers, and (2) speed freaks. (1) seems to be not an issue -- it can't be that much harder if so many SOAP toolkits appeared in a week -- and with 1000/queries/day maximum per user, (2) speed freaks need not apply."


Marc, I don't feel like you read my article all of the way through. I specifically said that speed was one of four or five "small benefits" compared to the "big benefit". The big benefit is proper integration with the Web and XML framework and I went into quite a bit of detail about things that can be accomplished in the REST-version of the service that cannot be accomplished in the HTTP-version of the service.


"For myself I like all of the things Microsoft has built on top of SOAP (like auto-generated docs and so on), and I could easily conceive of other people or companies building other cool things on top of it, too."


Once again, I don't feel you've understood one of my central points. Microsoft's auto-generated documentation is generated from the *WSDL*, not the SOAP. It is impossible to generate documentation from SOAP.


"Given that, I would just choose the one you like (as in, "would bet on if it were a horse") and experiment with it on its own until there is better data for business analysis."


If we only ever make decisions based on existing market share there will be no progress in the technology industry. "Oops, DOS has the majority of the market share. A Windows version of my word processor might be more functional but until Windows itself is more popular than DOS I won't bother." Sometimes you have to look and see what the technology enables. I was quite explicit about the sorts of integrative, declarative apps that are only possible in a URI-centric model.

precipice
2002-04-25 11:14:16
Re: Please re-read
My post was not intended as a point-by-point response to your article (which I did read to the end); instead I was stating my own viewpoint on the larger question of Google's technology choice. I think it's clear in what I wrote that I believe there are several factors for Google to consider in its choice (performance, supporting technologies, and market share among them) -- not that there is any one factor that should rule.


I do think you have good points about other kinds of applications or other infrastructure considerations (such as caching), and those discussions are definitely worth pursuing. My disagreement is that Google should not be castigated for choosing SOAP -- a widely accepted standard -- in the meantime. There are good business reasons for them to have made that choice.

jackogreen
2002-04-25 12:49:10
test