In the last two columns we talked about the emerging platform of the Web, and the use of Web APIs found through directories. Now I have something to show you that lives up to that hype, in essence a layer of technology, on-demand, that lives between the API provider and the API consumer, which is an API itself. It's the ProgrammableWeb API, which is an API-enabled registry/repository that allows you to find and access thousands of existing APIs out there.

Indeed, I could not say it better than their Web site:

"The ProgrammableWeb API gives you a simple and structured way to access the powerful registry and repository capabilities of ProgrammableWeb. This API for APIs lets you programmatically search and retrieve APIs, mashups, member profiles and other data from our catalog. Our write capabilities let you dynamically add new content as well as comment on existing entries."

As I've stated before, this really is the missing piece that will make the use of Web APIs take off in 2009 and 2010. While we have dozens of APIs coming online each week, there has not been a useful API-enabled registry/repository of reference that spans the Web. What the ProgrammableWeb API does is provide access to a common registry and repository of all working APIs that can be discovered and leveraged from on-demand or on-premise platforms. This includes what it is, why it exists, what it does, how to use it, and the experiences of others in the community.

This API is based on open standards including XML, RSS, OpenSearch, and the Atom Publishing Protocol, so you can get up to speed quickly and it works well with the existing tools and technologies you already know. Moreover, if you're familiar with Google's GData APIs you'll find that the concepts are very similar.

Why is this such a revolution? While the APIs have been showing up daily on the Web, from hundreds of providers doing everything from SMS text messaging to credit validation, Web developers have really had to know where to find them, and rely on their own experiences as to the value and usage of the APIs. Now there is a common registry and repository that can be bound to any number of mashup tools, PaaS-bound development environments, or even traditional application development tools to locate and leverage the Web APIs you'll need.

For instance, you can retrieve APIs by category, tag, or name. For a given API you can request a feed of that API's mashups, related links or user comments. Moreover, unlike earlier generation registries, this registry supports not just APIs using SOAP but also REST, XML-RPC, Atom, JavaScript, etc.

For example, to retrieve the list of APIs in the category Mapping, send an HTTP GET request to the following URL: http://api.programmableweb.com/apis/-/Mapping?apikey=123.

The response to this GET request will be an HTTP 200 status code and an OpenSearch-compatible feed that contains the first set of APIs in the category 'Mapping.' This example is on their Web site.

Each entry in the returned feed provides details on a single matching API from the directory:

<entry>
<id>http://www.programmableweb.com/api/google-maps</id>
<title type="text">Google Maps</title>
<link href="http://www.programmableweb.com/api/google-maps"></link>
<author>
<name></name>
</author>
<summary type="html">Mapping services</summary>
<content type="application/xml">
<pw:api xmlns:pw="http://www.programmableweb.com/api/opensearch/1.0/">
<rating>4.2</rating>
<name>Google Maps</name>
<label>Google Maps</label>
<description>Mapping services</description>

... additional elements here - see the Reference Guide for details:

</pw:api>
</content>
<updated>2005-12-05T05:52:02Z</updated>
</entry> [1]

What will be understood in a few years is that the use of an API registry/repository, such as this one, will be the "killer technology" that significantly reduces the friction of leveraging APIs. It's analogous to the rise of search engines in the middle 1990s that made the Web much more usable. Also, by creating a community around these APIs, API providers will become much better at understanding how developers leverage their APIs, and how they compare among other API providers. Thus there is a win-win when considering both the API producers and the consumers.

As far as I know, this is the first of its kind, and it was desperately needed as the Web moves from a visual to a non-visual development paradigm. As time goes on the use of this API will drive deeper into the enterprise development shops, and thus the use of APIs that exist outside of the firewall will increase as well. Developers will have more power to leverage external resources, and development will continue to get less expensive and provide more value.

Reference

1. From http://api.programmableweb.com/