Slides for the “Google APIs: Search, Advertising and Commerce” Keynote at SOA Kongress
November 22nd, 2006 · 1 Comment
Today I presented 5 Google APIs in a keynote at SOA Kongress in Mainz, Germany.
Google APIs: Search, Advertising and Commerce slides (PDF, HTML)
• API technologies: SOAP, REST and Ajax
• What: Google Ajax Search API
• Where: Google Maps API (Ajax)
• When: Google Calendar Data API (REST)
• Advertising: Google AdWords API (SOAP)
• Commerce: Google Checkout API (REST)
My presentation was a bit too long (103 slides, I have a tendency to cram too much content in my presos) but I was able to make justice to the 5 APIs and show many examples and demos. It was quite packed, I guess 100-150 people, and I’ve had very interesting conversations afterwards, with Frank Leymann from Stuttgart University, who was chairing the session, Reinhold Beckmann from Cordys, Ingo Meltzer from DaimlerChrysler, Eamonn Gabriel from Cape Clear and Thomas Leidinger from the Google office in Munich (I learnt that we have an office in Munich).
It was great to meet David Linthicum, who gave a great keynote about SOA, Web 2.0 and enterprise mashups later in the evening. I’m glad he liked my talk. He’s big on enterprise mashups, and when listening to his keynote I realized I had forgotten to speak about Kieden.
Kieden was a startup who created an integration between Salesforce.com and Google Adwords. On the Salesforce side they developped an AppExchange application, using Salesforce APIs and hosted platform, and on the Google side they used the AdWords API. Their product lets you manage your AdWords campaigns from Salesforce.com, and integrated the ads conversion into Salesforce reporting, letting you track a lead from the moment they clicked on a Google Ad to the close of a sale, potentially a few months later. I considered them as a posterchild for the AdWords API, and in september Salesforce.com acquired them. These guys really understood the opportunities offered by all these online services exposing APIs. When enterprises will start to realize the opportunities offered to them, I’m sure we’ll see enterprise mashups florish.
My talk’s main point is that Google exposes many services using different technologies, SOAP, REST, Ajax, so I see the Google APIs in their current state more as a set of Bridges between users and data and processes than a Platform.
I also echoed the discussion about SOAP vs REST that bloomed in geek blogs last week, after Pete Lacey’s hilarious socratic post the S stands for Simple and is well summarized in Tim Bray’s post S for Simple (Frank later informed me that W3C had ended up dropping the acronym because it was misleading). Nelson Minar’s post Why SOAP Sucks is a must read: based on hard learnt experience rather than ideology. Nelson is the guy who started APIs at Google, designing the SOAP Search API, and the AdWords API. I also highly recommend his ETech 2005 slides about that. He left Google in april. I miss him.
After a year animating the AdWords API developer community, I’d say SOAP/WSDL is OK if you’re in Java or .NET, but if your WS consumers are using anything else: Perl, Python, PHP(4, 5 is OK) or Ruby, you’re in trouble. Amusingly enough the developers who had less trouble were the Merjis guys with their OCAML client lib, but I suspect it’s because they’re really good, and rolled their own toolkit:-) Because of that in enterprise context where most environments are standardized around Java or .NET, they have less concern with WS-* interop issues.
1 response so far ↓
1 Richard Jones // Nov 23, 2006 at 5:36 am
Our AdWords API toolkit implements just about the minimum WSDL parsing required to deal with the AdWords API. I did, as a quick experiment, try using it to parse up the Amazon AWS and it doesn’t get very far (although to be fair I didn’t have the inclination to try and fix the problems — they might be minor). It also doesn’t even work against the Google Search API.
So I’m kind of torn two ways over SOAP.
It took us a lot of effort to write the WSDL parser, but the alternatives (using something like Java) weren’t very appealing for me. Now we’ve written it we get great benefits like the static type safety which is the single most important thing. It allows us to throw out a new release of our toolkit so quickly whenever you update the API version. All I do is “make clean; make” and then fix up all the problems which the compiler turns up, like fields in AdWords structures which have been added or removed.
If AdWords API had been done using REST then we would have got started a lot quicker, but we wouldn’t have the type safety, so our programs would be failing all over the place at runtime.
The problem with SOAP then is definitely the complexity of WSDL (or rather, XML Schema embedded in WSDL documents), and its seeming lack of definition and huge scope. REST + type safety would probably have the same problems unless they ditched XML Schema and used something simpler.
By the way I strongly disagree with Nelson Minar’s “Why SOAP sucks” posting, particularly where he says:
This sort of sloppiness is what gives software a bad name. I mean considering the number of bugs caused by overflowing fixed size counters (Y2K anyone?) you’d think that programmers would learn why integer size is not merely “cosmetic”.
Leave a Comment