Social standards: understanding Google's new APIs for Buzz

Google unveiled new APIs for its Buzz social networking service on Wednesday during a presentation at the company’s I/O developer conference. The new APIs will make it possible for third-party developers to write software—such as desktop and mobile client applications—that can read and post content on Buzz. The Buzz APIs are built on top of open standards to enable broad compatibility with other services.

Google’s Chris Chabot started the session by describing Google’s vision for social networking. The Web is becoming increasingly social, he explained, but social networking is heavily fragmented due to the multitude of disparate services that are popular among users. Google hopes to unify social networking and make it a pervasive part of the Internet experience, but not at the cost of diversity and rich competition in the marketplace. The solution, said Chabot, is to facilitate interoperability through open standards. He said that Google wants Buzz to be part of a bigger ecosystem, one that includes a healthy quantity of good third-party software.

A number of compelling standards that are emerging in the social networking space have the potential to reduce fragmentation, simplify client application development, and enable competing services to work together seamlessly. (The list includes OAuth, Activity Streams, and Salmon.) With the exception of Salmon, the standards that Google has selected for Buzz are already used by some major social networking Web sites and are rapidly gaining traction.

Activity Streams, also known as Atom Activity Extensions, describes a set of enhancements to the XML-based Atom feed format that can be used to express a sequence of activities or items in a timeline. There’s also a JSON-based output format that Google decided to offer alongside Atom in response to requests from application developers (I favor JSON myself because it’s lighter, faster to parse, and maps cleanly to conventional hash and list containers).

As some readers might recall, we discussed Activity Streams at length when Facebook adopted the standard last year. Other prominent adopters include MySpace and TypePad. Due to the growing body of supporters, it’s likely that there will eventually be Activity Streams client software that will track social messages from multiple sites in much the same way that users today run generic news readers to follow RSS and conventional Atom feeds.

Chabot said that Google’s new APIs are still incomplete and subject to change. As such, the API support is currently made available as a “Labs” feature, signifying its experimental nature. He described several gaps in functionality that will prevent third-party developers from building fully-featured client applications.

For example, messages that are not public will not be accessible through the API, even in cases where an authenticated user has permission to see the message. That particular limitation exists because the company is taking a relatively conservative stance on potential privacy issues during the initial rollout of the API. It seems like Google learned some important lessons from the fallout of the high-profile privacy failures that marred Buzz’s launch.

Several of Google’s partners received early access to the APIs during a trial period. As a result, there are a handful of popular applications available today with built-in support for Google Buzz. During the presentation at I/O, developers from Seesmic and Socialwok gave brief demos of their Buzz-enabled software. The level of integration with the service that is offered by these third-party applications appears to be relatively strong.

After the presentation, I spent some time myself experimentally hacking Buzz support into Gwibber, my own multinetwork microblogging application. The REST APIs work reasonably well and appear to be soundly architected. My only complaint is that the OAuth-based authentication mechanism could be a lot more desktop-friendly. I’d like to see Google adopt a mechanism similar to Twitter’s xAuth, which allows applications to obtain an access token by supplying the user’s regular credentials (not to be confused with Meebo’s XAuth, which is completely different). I’m planning to publish a Gwibber branch with preliminary Buzz support at some point this weekend. Ars will also have a programming tutorial next week.

To simplify and accelerate third-party development, Google has supplied client library implementations for several programming languages, including Python and PHP. The company has also provided a convenient command-line tool that allows developers to make API calls and see the output in the terminal. This makes it easier to experiment with the API and test the endpoints during development and debugging.

The availability of APIs will expand Buzz from a service into a platform. Google’s commitment to using existing standards could be beneficial in the long run, especially as client application developers work to support more services in their software.