Nooooo!

I've just been developing something using this. Just my luck.

The AJAX Search API isn't quite the same. But, with custom search engine being available now, there's most likely a solution for 99% of people out there currently.

You can still use the SOAP API, right? It's just not actively supported. Just like Windows 98.

Ionut, I think you're right. That what I understood it to mean too, especially since they said they've kept the documentation on the site for developers who are already using it.

> You can still use the SOAP API, right? It's just
> not actively supported. Just like Windows 98.

Except that the AJAX API is something very different from the SOAP API, whereas Windows XP, 2000 etc. are (at least theoretically) working updates to Windows 98 which people can switch to. Besides, the Google Search API is flaky as hell, and Google just admitted they stopped supporting it... so as the final straw of hope for improvement in this area is gone, I would not suggest using it anymore – rather, I suggest developers start removing existing API-usage from their code. Who knows how long till Google completely drops this?

Google will release a search API under the GData umbrella. And if you want a proof, there's something similar already available.

http://googlesystem.blogspot.com/2006/11/secret-google-json-api.html

Monopoly? You shall have no tools besides Google's own tools. It's also an Anti-SEO measure. Now basically all SEO tools break the Google TOS and can be shut down.

Repeat after me:
Google SOAP API still works for sites that already use it.

> Google will release a search API under the GData umbrella.

Maybe. Still I can't remember Microsoft ever giving up support for a version of Windows – a product they want the community to keep placing trust in – *before* they released the follow-up version (though a Microsoft history buff may prove me wrong!). I use the SOAP API at FindForward.com, and if the constant flakiness of their API was the metaphorical Google turning their backs at us, then this last move is the metaphorical Google showing us the middle finger. Maybe some will hang around with this API waiting for further signals, but I think it's time to move on... and Yahoo's API seems to be a much better replacement in this context than the Google AJAX API. And whenever Google decides to release another search API as part of Gdata, well, the cards will be shuffled again.

> Google SOAP API still works for sites that already use it.

No, Ionut – it's flaky as hell, meaning it may or may not work, and it has been like that for quite some time. Previously, you might have told a developer, "well, have you contacted Google support?" This is now officially not a choice anymore (not that I'm saying it previously helped!).

Here's a site that uses it: http://www.doubletrust.net . It seems to work just fine.

>> it's flaky as hell, meaning it may or may
>> not work, and it has been like that for quite some time.
>
> Here's a site that uses it: doubletrust.net . It seems
> to work just fine.

Yes, flakiness doesn't mean it never works. It just means it doesn't always work. I know you know what I mean because your logic thinking is good:
http://blogoscoped.com/forum/78519.html#id78541

And I'm judging from experience, as you might remember:
http://blogoscoped.com/archive/2006-11-14.html#n82

It might be connected to several factors, e.g. it might be a combination with the programming language used (PHP in my case). Still, PHP works non-flaky with Yahoo's API on this server, so it's a solvable problem. (Well, the Yahoo API isn't totally stable, but in completely different ways – it's sometimes very slow, and if I'm not mistaken, they also changed the XML namespace declaration header before).

I like this definition:

"A system that is *flaky* is working, sort of – enough that you are tempted to try to use it – but fails frequently enough that the odds in favor of finishing what you start are low. "

http://www.comedia.com/hot/jargon-4.2.3/html/entry/flaky.html

Yeah, that fits with the SOAP API, from my experience :)

Just to echo what Philipp said, as another user of the SOAP API, I would agree that "flakey" is the correct expression. It is not uncommon in my experience for it to error out, return nonsense results ... and it is slow, slow, slow.

Having said all that, it was a nice interface – sorry to see this change since I thought if anything, Google could address the shortcoming's mentioned above (plus allow more liberal number of queries/key) and then it would ROCK.

alek

P.S. I read the announcement the same way as "Ionut Alex. Chitu" does in that "Google SOAP API still works for sites that already use it" ... you just won't be able to request any more license keys. However, I can't help but believe it will get more "flaky" over time now.

Bad, bad, idea. It's saying "Don't play nice and use official-sanctioned API. Screenscrape instead!".

This is really sad.

Sure there are a few black-hat applications for the SOAP API, but with a limit of 1000 queries per key per day it isn't scalable enough (and using multiple keys on the same IP seems risky :-)).

We don't know how long the API will continue to work (on and off.... I have to retry often – does that use up my queries? – to get any result) and there is no plug-in replacement in sight. Pushing the AJAX version as a replacement is a joke. Come on....

Screen scraping Goolge or divert to Yahoo? If Yahoo is smart, they'll up their limits to 10k or so and grab another user group from Google (what's next?). I'd prefer to keep using Google, but screenscraping is not a long-term alternative.

Special offer. If you want keys, go to this page:
http://api.google.com/createkey

You must be logged in. You'll get an error page, but that's OK. Check your mail.

Don't forget. One email = one key.

> I'd prefer to keep using Google, but screenscraping
> is not a long-term alternative.

I wonder if this'll be the start of a community-driven Google screenscraping framework. E.g. a PHP5 class with public functions returning image search result, web search results, group search results, stuff like that. This class would then be community-maintained in open source style to accompany changes in Google.com's HTML...

Yeah, or just move ot Yahoo...

No need for that. What about the JSON thingie from SearchMash?

http://blogoscoped.com/forum/79963.html#id79971

Of course, Google can shut down the site.

Exactly, hypothetically speaking, a community-maintained screenscraping framework would be a "wrapper" around Google's server, releasing an update to the *.php class (or whatever it is) whenever Google shuts down a site, changes their HTML, etc. – you'd just plug-n-play the updated class into your existing code. So right now, perhaps that class is using JSON data from Searchmash because that turns out to be the best way. Maybe tomorrow, the details change. Maybe the wrapper is even cross-company so that behind the scenes, the public function "getAnswerSearchResult()" would've switched from Google Answers to Yahoo Answers last month :)

Implementing search-as-a-service through community action :-)

Reminds me I really should do the API stuff I've been thinking about doing.

"I just learned that two weeks ago Google officially put the SOAP search API on end of life status. That was my first project at Google..." -> http://www.somebits.com/weblog/tech/googleSearchAPI.html

"This is such a bad move because the Google API was *the* canonical example of how web services work. Not only is Google Hacks based on this API, but hundreds of other books and online examples use the Google API to show how to incorporate content from another site into a 3rd party application." -> http://radar.oreilly.com/archives/2006/12/google_depreciates_SOAP_API.html

Definitely a disappointing move.

Personally I think they'll release something far better supported under the GData umbrella (as Ionut suggests), the rest of their gdata APIs are quite good.

Of course it is definitely weird that they chose to kill the SOAP service *before* introducing a replacement. Same with answers.

You're right Philipp, this is the opposite of what Microsoft does, but then again, their insistence of backward compatibility and never-kill-an-api is often brought up as a reason why they move so slowly and lumberingly. But like I said in a post earlier, if Google want to get developers onboard they're going to need to build some trust – this isn't a good start!

(Google changed their statement on the SOAP API's homepage, so I updated the post.)