InfoQ

News

Google Deprecates SOAP Search API

Posted by Stefan Tilkov on Dec 19, 2006

Community
SOA
Topics
REST ,
Web Services
Tags
Public APIs ,
Google ,
SOAP

Quietly, Google has deprecated its SOAP Search API, withdrawing one of the most prominent examples of Web service usage on the Internet. The remaining AJAX Search API is only a partial replacement.

The Google SOAP Search API enabled its users to submit search, cache, and spelling requests by means of SOAP 1.1 (using RPC/encoded style) . The service was described page now displays a prominent notice:

As of December 5, 2006, we are no longer actively supporting the SOAP Search API. We encourage you to use the AJAX Search API instead.

Google Product Manager Tom Stocky clarified what this change actually means for developers in a posting to the Google Web APIs discussion group:

Just to clarify, we're not planning to shut off the SOAP Search API service for people who are already using it. The change is that we're not accepting new requests for SOAP Search API keys and are no longer actively supporting it so that we can concentrate our efforts on the AJAX Search API.

The AJAX Search API Tom refers to is a Javascript library that enables embedding Google Search in web pages; using it for back-end tasks (as was possible with the SOAP Search API) does not seem like something that is intended or supported. While the AJAX Search adds some features, such as the ability to search video, news, maps, and blogs, it lacks support for filtering, specifying languages, and the direct cache and spelling access. (It's also questionable whether it's AJAX at all, as it does not actally use XmlHttpRequest.)

Some reactions from the blogosphere view this as another sign of the declining acceptance of SOAP-based Web services on the Internet, such as Steve Loughran, whose post is titled "The end of SOAP" and is concluded with this line:

Slowly, all over the world, the lights on the SOAP endpoints are going out.

This seems a premature declaration of victory for the REST folks in the eternal REST-vs.-SOAP debate, though, as Google does not offer any comparable API at all ( (in contrast to Yahoo!, who have had a REST API for quite some time). Dave Megginson highlights this aspect:

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.

Whether Google's decision is based more on business reasons or on technical aspects, it's definitely sad to see one of the most well-known (and easily understandable) examples of Web services disappear. But as John Gruber writes:

They did call it a “beta”, though.

Not a big deal by Sam Pullara Posted Dec 19, 2006 11:41 AM
Re: Not a big deal by Ivan Lazarte Posted Dec 20, 2006 10:31 AM
Re: Not a big deal by John Reynolds Posted Dec 21, 2006 7:46 AM
  1. Back to top

    Not a big deal

    Dec 19, 2006 11:41 AM by Sam Pullara

    Use the Yahoo Search API. Higher daily limits and REST based with commercial licensing available for heavy users.

    www.programmableweb.com/api/Yahoo

  2. Back to top

    Re: Not a big deal

    Dec 20, 2006 10:31 AM by Ivan Lazarte

    I also suspect Google will relaunch their SOAP (or a REST version) with commercial value attached to it. It would be a serious misstep to force everyone to use their "ajax" alternative; especially those who want count the availability of pure data.

  3. Back to top

    Re: Not a big deal

    Dec 21, 2006 7:46 AM by John Reynolds

    This decision really is all about business... Services must make economic sense, or they can't be offered. It has nothing to do with technical merit.

Educational Content

Brian Marick on 4 Challenges and 5 Guiding Values of Agile Software Development

Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).

Are You a Software Architect?

The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?

Agile – A Way of Life and Pragmatic Use of Authority

The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.

Getting Started with Grails, Second Edition

"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?

Using ITIL V3 as a Foundation for SOA Governance

Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.

Adrian Colyer on AspectJ, tc Server and dm Server

SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.

Adam Wiggins on Heroku

Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.

SOA as an Architectural Pattern: Best Practices in Software Architecture

For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.