An API at Launch: Reflecting on the Google Buzz API »

Remember when videogames used to be released on different platforms at different times? One platform like the PlayStation version would lead, while other versions trailed behind. Then at some point, publishers realized they could make a bigger splash by landing all versions in stores at once—the simultaneous release.

Today on the web we expect an API to lag the launch of a new webservice. So it was interesting to see Google Buzz tout its API on day 1. On one hand the shiny new Buzz API is not much more than a stub, though on the other it is a promise to deliver a robust API.

But at this time, you can't even post an update to Buzz via the API. You also can't mute a buzz. You can't even search. It's read-only; all you can do with the API is get the Atom feed for a user's Buzz, which doesn't include important metadata like location information. You could argue, as Fred Wilson has, that any read-only API shouldn't even qualify as an API.

There ARE things to like about the promise of the Buzz API. It's a stake-in-the-ground to support existing standards like PortableContacts, the Social Graph API, and OAuth. Important protocols like PubSubHubbub, Salmon, and WebFinger should get a good boost too. Yay for open standards!

But there are some concerns too. In order to build on top of the Buzz API, you may have to become familiar with the disparate set of technologies listed above. And if you prefer JSON or raw XML responses to Atom, you'll have to wait (FWIW, format conversion is one of the many tricks that Sonoa's ServiceNet does right out-of-the-box).

What could Google do to encourage Buzz innovation? After all, isn't that a big reason why APIs get released? They could wrap the various standards they plan to support with a look and feel similar to the full Buzz API (whenever it lands). They could emulate the Twitter API, like Wordpress and Tumblr have done, but that brings up issues of licensing—something that Googler Dewitt Clinton has pursued with Twitter's Ryan Sarver. Still, that kind of familiarity would only drive Buzz adoption with developers already versed in Twitter. In some ways Buzz resembles FriendFeed more than Twitter. So why not map the FriendFeed API pattern onto the Buzz API, as Dave Winer has suggested (again not without issues)?

Not having API in 2010 is like a not having a website in 1997. How long will it be until everyone launches both of them at the same time?

(logo by Alex Gillis)