What's next after the Google API?
Saturday, April 13, 2002 by Dave Winer.
My two cents 
Here's why I think the release of the Google API is significant.
1. It works. You can make a SOAP call to Google and get a response.
2. It didn't take very long for them to do it. There was no excruciating phase lasting years with hundreds of people getting their shot at fixing it and changing it. It stayed simple.
3. It's compatible. Within hours samples were available for AppleScript, C++, Frontier/Radio UserLand, Movable Type, Perl, PHP, Python, Ruby, Tcl and Visual Basic. Glue for Java, .Net and Perl were included in Google's developer package. No one hit any bumps or dead-ends, as far as I know.
4. Google is the leading search engine. When the Macintosh platform went through this layer of technology in the early 90s, a simple utility called Stuffit got it started. Then Pagemaker, Filemaker, Quark, the Finder; and from there, scripting interfaces became commonplace. Some may want an orderly deployment of common practices, but leaders can move more quickly, and they will, and that's good.
5. Developers are interested. There are enough people who are willing to try out an idea, overlook its flaws, and believe. That says that other market leaders who provide a programmatic interface to their data will likely get attention from developers. Could Amazon implement a money-making SOAP interface? Without a doubt. Same for Yahoo and eBay.
6. SOAP is good enough. It may not be perfect, it may not have all the answers, but there are useful things you can do with it. Google helped SOAP out of a tight corner.
7. It opens a conversation. Before this release, from Google's point of view, we were all users. Now some of us are developers. We get another chance to define what that means, based on what we learned being developers for Apple, IBM, Apple again, Netscape, the Internet, Microsoft and now the Internet again. It's a good time for a fresh start.
Hello World
We're at the Hello World stage again. It's like the hobbyist period of personal computing, or MacWrite/MacPaint in 1984, or the early days of the Web when the blink tag was a minor miracle. Same idea.
Yesterday I ran a survey on Scripting News asking if the Google API is useful. The number one answer was "Yes, there are lots of possibilities." The second most popular choice was "The lightning bolt hasn't hit me yet."
A tentative step
On the other hand, Google's first steps in SOAP are tentative. There are limits on the number of queries per day, the number of hits returned and on using the service commercially. And the most juicy services don't yet have interfaces. For example, it would be great to get a random picture of Tiny Tim to display on my weblog (yesterday would have been his 70th birthday) each time I update. Google can find it for me. Webloggers love kitschy stuff like that. (OK, I admit it, I love that kind of stuff, can't speak for all the bloggers.)
Correcting the spelling of a phrase or sentence is also interesting, and Google is very good at it, but with the tentativeness, we can't build a commercial feature. (And it isn't the right interface. For spell-check, we need to pass a document to the engine and get back a list of misspelled words with suggestions for correct spellings. I'm sure I'm not telling the Google people anything they don't already know.)
Next steps
There are two sides to search -- crawling and queries. We now have a partial interface to the query side of search. An obvious next step is to complete the interface. But to really get the benefit of the connection between content management and search, the other side must have an API as well. When a website updates, it should be able to ping the search engine, saying "I just updated." The crawler doesn't have to believe the ping, it can verify for itself that the site has changed. And if, for some reason, its policies say that the site isn't one that the search engine considers important, it can ignore the ping.
Today Google has a two-day turnaround for fast-changing sites. It seems that with a simple SOAP interface for update notification, for which there is prior art, the two-day turnaround could become an hour or less. The benefit is that Google's index would become more current, more just-in-time, more competitive, more valuable.
Also, put a pricetag on the service asap. $15 per year per user, for a maximum of 1000 queries per day. Instead of disallowing commercial apps, become one. Make money. This is essential if Google and its nascent developer community are to grow and survive to do more cool stuff with the Internet.
Longer term
Google belongs on my desktop. I have a sea of information here, accumulated over many years, and most of it is useless because I can never find anything when I look for it.
When Google arrives on the desktop, it will have the same SOAP interface that the global Google has. All the tools that work with the centralized service will also work on the desktop.
Simplicity matters
But all this is secondary. As a consistent evangelist of Internet-based scripting, Google's move helps enormously. They got people thinking. If the Internet is anything, it's a collection of minds and wills. If the evidence is there, the minds believe. Web services can make you think, make you want more. The art and science of Internet scripting can be transparently simple. The new technology is for curious developers and hobbyists, for the motivated and the excitable, for people learning and exploring. At the start it has to be that simple so lots of people can get on board.
Dave Winer
PS: API stands for Application Program Interface. Think of an API as a wire that connects a machine to an application. A gas nozzle at a gas station is like an API. The car is the app, driving is the platform, which has many APIs. Roads are one. An ignition key is another. They're all important.