Google Releases an API for Their Database

Ben Wills writes "Yahoo! announced that Google Released an API last Thursday. "The service, launched Thursday, is called Google Web APIs, for application programming interfaces. The tools let noncommercial software developers "query more than 2 billion Web documents directly from their own computer programs," according to Google's Web site. For now, the service is free." Google just keeps pushing the limits."

Comments

No support for image or usenet queries...

[casio282]

Sadly, though, there is no support in the API for queries on their image or usenet "groups" indices, according to the API FAQ:

2. Can Google APIs be used to access Google Groups? Image search? Directory search?

No. The Google Web APIs service can only be used to search Google's main index of 2 billion web pages.

I'll have to keep on parsin'... Maybe some day.

For the sake of the revolution of the world!

[Agelmar]

The world can now be revolutionized! We can get Google searches on Microsoft.com! The pigeons will come out of their cages and peck the buttons on the Microsoft servers, thus shutting down the evil megacorporation! Hail Google for saving the world! The pigeons will save us all, hail the open API!

Slashdot Releases an API for Their Database

[ajakk]

PsPrEditor writes: "Yahoo announced that Slashdot Released an API last Monday. "The service, launched Monday, is called SlashPI. It will allow users to remove duplicate stories that have been plaguing /. for the past year. ""

Re:Slashdot Releases an API for Their Database

[jeffehobbs]

In other news, PsPrEditor writes: "Yahoo announced that Slashdot Released an API last Monday. "The service, launched Monday, is called SlashPI. It will allow users to remove duplicate stories that have been plaguing /. for the past year. ""

Google saving bandwidth?

[shaldannon]

Why do I get the feeling that Google is doing this to save bandwidth? How many people do you thing scrape Google for results? How much load are they going to save if people use the API rather than searching and scraping? That's what I thought...

Re:Google saving bandwidth?

[babbage]

Well, exactly. This is really where things should be going. Think about it. If a user can express exactly what they want from an online resource in a terse but complete way, then both the user and the resource provider come out ahead. Neither side wants to deal with the extra overhead of serving whole pages of HTML formatting when [a] you just want the hits on a given search query and [b] Google doesn't want to pay the extra bandwidth charges.

Allowing power users to target requests more efficiently is a boost to both sides here -- even if Google doesn't charge a nominal fee for this, the bandwidth savings could still put them ahead of where they would have been under a more traditional HTTP/HTML transaction. You phrase your comment in a very cynical way, but really this seems like a great thing to me. One of the biggest burdens in getting info from the web is having to manually scrape it out of a web browser (or muck around with say LWP and HTML parsers). With an API like this, we can see more applications such as Watson, that aggregate the data & cut through all the web crap that makes finding information tedious. This is where everything is going with SOAP, .NET, MONO, XML-RPC, and so on, and I for one am glad to see a great company like Google leading the way.

Google more open to "google bombing" now?

[cetan]

An interesting article on K5

http://www.kuro5hin.org/story/2002/4/15/72154/5065

talks about how now Google bombing is even more effective with this release.

What web services were meant to be?

[SirSlud]

Am I one of the only people that contend that THIS is what the whole 'web services' thing is all about?

I think this is ultra cool. Imagine, if you made an application that had skins or used plugins, or whatever. You could have an in-app browser, powered by google, to search for new add-ons to applications, etc.

Actually, the possibilities are quite cool.

Heh, Google faster than Microsoft. Perfect timing.

[Baki]

Microsoft, claiming everyone should use .NET to be able to use web services (WSDL) just announced their first web service (mappoint) but google beats them. Plus, google shows you don't need .NET but can just as well use Java to make use of XML web services. MSFT must be quite pissed because of this, google stealing the web services show for now.

Apart from that I think it is a pity that noone comes up with a Corba-over-HTTP standard. As an API, Corba IDL is nicer and more compact than WSDL, and all tool support is already there. WSDL offers no advantages over Corba. The only difference is the use of XML instead of (easy) IDL, and using HTTP as transport mechanism. Corba is transport mechanism independant; current implementations mostly use IIOP, but one could just as well implement Corba using HTTP as transport. Hell, you could even use some XML-over-HTTP as transport, to satisfy all XML freaks that think any machine-to-machine data nowadays should be human readable.

The only justification for XML web services is that MSFT hates Corba (because of their Not Invented Here syndrome they invented COM+ to compete, also helping vendor lock in) thus they had to come up with something else; switching to Corba would mean they loose their face.

Sounds familiar

[Jaeger]

I'm glad the army of highly-trained rodents that processes Slashdot submissions was able to catch these reduntant stories. We've seen this a few times before:

• Google Releases Web APIs by Hemos with 142 comments on 11:57 Friday 12 April 2002
• Google to Offer API by CmdrTaco with 218 comments on 17:54 Saturday 06 April 2002

The first story even included a link to the API page on Google's site.

Look here for the xml-rpc interface

[codepunk]

Google xml-rpc interface

I personally refuse to support and or recommend anyone using SOAP web services due to the patent fiasco. I asked on the xml-rpc list if anyone knew of a xml-rpc gateway and Dave Winer immediately jumped to the challange and put up a public gateway.

Thanx Dave