RESTful approaches to APIs have made them easier to deploy and consume, leading to a recent explosion in the number of available APIs. One byproduct of such growth is there are a lot of APIs offering similar or even duplicate services, but that have very different approaches to delivering their APIs. Cloud computing and social networking are two areas where we’ve seen the growth in APIs. As the number of APIs grow, the need for interoperability increases.
Since REST is only a style, not a an actual standard, there are many interpretations of exactly what is RESTful, resulting in many differences between seemingly identical APIs. This can make API integration across many similar service providers a lot of work. For example, when developers want to use multiple cloud computing providers like Amazon Web Services or the Rackspace Cloud, programmers have to write separate code for each provider. Similarly when developers want to pull social streams from Facebook and Google Buzz, they have to write code for each API.
There are two approaches to bridging the gap between API providers: build a unified API that funnels different services through one API; or push for common API standards that everyone agrees on.
For example, OpenStack wants to define a standard for deploying cloud infrastructure and associated APIs, and the activity streams project wants to provide a standard for syndicating social activities around the web.
Another solution is a unified API, something like DeltaCloud for cloud computing and Windsoc for social networks. Deltacloud and Windsoc are both trying to bridge the differences between commonly-used APIs, providing a single API interface for developers to use.
DeltaCloud provides a standard interface across Amazon Web Services, GoGrid, Rackspace and other cloud providers, while Windsoc provides a single interface across Facebook, Twitter, Google Buzz and other social networks using the activity stream format.
Although both DeltaCloud and WindSoc provide solutions, API standards are a much healthier approach to this problem. They provide a standard interface across any API, allowing APIs to be distributed and owned by many providers. The downside is that standards can take years, and sometimes never gain industry-wide acceptance.
Unified API providers find success by providing a single interface across many APIs, making it easier for developers to access, and can be deployed quicker than an industry standard. The downside of unified APIs is that they create a single point of entry within the control of one provider, and providers have to stay in tune with all changes made across each API they support.
The race is on: can API standards evolve fast enough, or will unified APIs meet the demands of the development community? Or are unified APIs just an interim solution until we can define common standards?