Google Announces Definite End of Their SOAP Search API

Google in a blog post discussing their new Google Code Labs overview page mentions that they’ll end the Google SOAP Search API for good on August 31st this year. So far, while it was announced as unsupported and didn’t accept new sign-ups since December 2006 already, it was still working for those who used it in their past projects. “Since then” Google says their SOAP API has “been steadily declining in usage”. In an email sent out to developers who had once signed up for an API key, Google apologized.
I’m making extensive use of the SOAP Search API over at FindForward.com, an older playground for search experiments. Perhaps one of the simplest routes to go once the SOAP API is dead is to create a module which emulates that API using Google’s REST API. Writing a screenscraping wrapper class might also be just as feasible, and it would even survive if Google decides to kill of the REST API one day; such a wrapper may also support those features which the SOAP API had but the REST API doesn’t (querying for the Google cache of a page, and spellchecking, the least).

Google UK didn’t update their SOAP API homepage yet, still showing the old version. Google originally launched the SOAP API in 2002 (according to Ionut).
When you do use the REST API, Google points out this bit: “each search performed with the API must be the direct result of a user action. Automated searching is strictly prohibited, as is permanently storing any search results.”
Companies may do well to not support dead-end projects forever. The bigger problem with Google’s ending of projects is that they rarely give you an honest answer as to why they ended something, as only that could help you on which present and future products and APIs you should bet. The answer for canceling SOAP support may be that, as the casual-API world is moving towards REST + JSON*, there’s too much overhead involved in the protocol. Here’s a bit of background from ex-Google employee Nelson Minar from November 2006:
As someone who bears some past responsibility for well used SOAP services (Google’s APIs for search and AdWords) let me say now I’d never choose to use SOAP and WSDL again. I was wrong.
The promise of SOAP and WSDL was removing all the plumbing. When you look at SOAP client examples, they’re two lines of code. “Generate proxy. RPC to proxy.” And for toys, that actually works. But for serious things it doesn’t. I don’t have the space to explain all the problems right now (if you’ve seen my talks at O’Reilly conferences, you know), but they boil down to massive interoperability problems. Good lord, you can’t even pass a number between languages reliably, much less arrays, or dates, or structures that can be null, or... It just doesn’t work. Maybe with enough effort SOAP interop could eventually be made to work. It’s not such a problem if you’re writing both the client and the server. But if you’re publishing a server for others to use? Forget it.
The deeper problem with SOAP is strong typing. WSDL accomplishes its magic via XML Schema and strongly typed messages. But strong typing is a bad choice for loosely coupled distributed systems. The moment you need to change anything, the type signature changes and all the clients that were built to your earlier protocol spec break. And I don’t just mean major semantic changes break things, but cosmetic things like accepting a 64 bit int where you use used to only accept 32 bit ints, or making a parameter optional. SOAP, in practice, is incredibly brittle. If you’re building a web service for the world to use, you need to make it flexible and loose and a bit sloppy. Strong typing is the wrong choice.
The REST / HTTP+POX services typically assume that the clients will be flexible and can make sense of messages, even if they change a bit. And in practice this seems to work pretty well. My favourite API to use is the Flickr API, and my favourite client for it is 48 lines of code. It supports 100+ Flickr API methods. How? Fast and loose. And it works great.