Some more research, other posts and bits of feedback show that the turning off of the google SOAP APIs is not good, because the (current) alternative is not an API. It is not for programs, it is for pages. The SOAP API worked at the model level, giving back results you can work with, but the AJAX API hands off a bit of your web page with results that are targeted at people. It is view, not model.

Maybe Google have an alternate RESTy API in the pipeline. Alternatively they've made a business decision that they'd rather take over a bit of web page real estate (getting brand recognition, possibly click through revenue, advertising &c). Rather than search-as-a-service, it is search-as-a-GUI-feature

Technologies aside, this shows one of the risks of relying on an external service for system functionality. Everyone using the SOAP API is stuffed, as there is no direct replacement. Everyone who was downstream of the site is stuffed, even if they didnt know who did the searches.

To update a Lamport quote to the SOA era, You know you have a distributed system, when a company you didn't know you had a relationship changes their business plan and your application stops working

The SOAP API users may be able to switch to the Yahoo and MS APIs. I'd expect the latter to last longer, as Microsoft do have a SOAP stack to support, and lots of enterprise users who may be building use of it into their apps.

Someone could be generous and provide a bridge between the google SOAP APIs and their own; a bridge service at a new URL. Of course, if UDDI had taken off, and all search engine vendors had provided a unified search API, your app would just switch transparently to another vendor. Which shows why one aspect of UDDI was good -it was meant to reduce the friction when switching between vendors.

In a world without an ecosystem of plug-in replacement services, you end up hard coding dependencies on Yahoo, Amazon, google, MS Live, and the like. In which case you have to hope they keep their service up for as long as you need it. Which means that it must be profitable to them. All users of the service API, be it SOAP, REST or something else (DCOM over HTTP?), have to bring in enough money to cover operational costs of the service. Furthermore, it must be profitable enough that the management team doesn't start looking at what else would be possible if the machines and people were dedicated to something else. You have to cover the opportunity cost, alongside the operational overheads.

Think about that the next time you generate WSDL from some endpoint, write a little mashup or even a python script to fetch some XML from a remote URL.