Washing Out The SOAP

I'm not really very fluent in this stuff, but when Tim Bray worries about it, and then I read this on a site he points to: Forget about the SOAP vs. REST debate for a second, since most of the world doesn’t care. Google’s search API let you send…

Forget about the SOAP vs. REST debate for a second, since most of the world doesn’t care. Google’s search API let you send a search query to Google from your web site’s backend, get the results, then do anything you want with them: show them on your web page, mash them up with data from other sites, etc. The replacement, Google AJAX API, forces you to hand over part of your web page to Google so that Google can display the search box and show the results the way they want (with a few token user configuration options), just as people do with Google AdSense ads or YouTube videos. Other than screen scraping, like in the bad old days, there’s no way for you to process the search results programmatically — you just have to let Google display them as a black box (so to speak) somewhere on your page.

3 thoughts on “Washing Out The SOAP”

You can (separately) argue that SOAP sucks and it a bloated API, but unless Google replaces it with a REST-ish API based on XMLRPC or even GData then this is a business decision to close their doors to developer mash-ups.

I’m a big Google fan, but this is a strange move to say the least, since so much of their developer cred is based on them leading the way in the world of mash-ups and APIs.

I’ve seen many developer blogs follow to the logical conclusion that “Yahoo and Ask.com still offer search results via a service…”

I said before and I will say it again, Google does not know the difference between AJAX and SOAP. On the other hand, if they do know the difference, then they are clearly making this move only to control the results delivered by the API for their own purposes. Unfortunately, this is going to result in a big push by the tech community towards the other search API’s such as Yahoo!