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.