Standard but not Standards

It is highly unlikely that any single, non-trivial application will be able to independently contain within itself all necessary functions. Instead, it must communicate and interact with other pieces of software in order to obtain data, process it, and send it elsewhere. This becomes especially true of any piece of software that depends on the Internet for its operation. As a means of standardizing these interactions, software must implement application programming interfaces (or APIs) which define exact types of input they can accept and output they can generate.

Web APIs are the way for outside programmers to build new tools for using a website and its services, besides what the site itself provides to a user through a web browser. They also allow independent network services to communicate information to each other. Popular examples include mobile phone applications for posting pictures, blogs, or status updates to a web service without having to load a full web browser.

Sometimes, a walled garden owner provides an API to let “others” make some of the attractions in the garden, and get access to their users and perhaps some of the data lying in their silo in return. This enriches both the garden and the attraction owner, so it’s a common strategy that brings a steady influx of eager third-party developers to Facebook, Apple’s App Store and other popular closed platforms.

On the face of it, a website that publishes an API and allows other websites and applications to connect to it and avail themselves of its services would seem to fit the very definition of an “open” Web. For certain, the existence of APIs do appear to allow developers (and by extension users) more choice about how to access and interact with their favorite online services. APIs also allow developers to build novel new applications on top of existing online services.

Although Web APIs are in their own right publicly defined, they are far from published standards in the strict sense, namely as open and public standards put in place by a neutral entity such as the World Wide Web Consortium (W3C). Instead, APIs are created entirely at the whim of the website that provides them. They can change at any time, and there is no guarantee that they will provide the functionality that the user might need or request.

There is usually also no easy way to use a program written for one API on another website. For example, the desktop client for the an online radio service last.fm¹  does not mirror that of services of other music sites like Pandora or Spotify. In other words, the APIs to not use publicly vetted standards to transfer data, and most often, developers have to program applications anew for each platform. The exception to this would be the APIs built into popular open-source content management systems (CMSes) like Wordpress, MediaWiki or Drupal, so they work for most of the many sites using them.

As one example among many, an entire ecosystem of third party websites and applications has grown up around the Twitter API. So much so that the company has revealed that 75% of its internet traffic comes through its API rather than its website. While this has allowed users a constellation of choice about how to send and receive messages from Twitter, it has nevertheless put developers and users alike at the mercy of the single company providing the service: Twitter. Keep in mind that the company is under no contractual obligation to continue to make its API available to anyone. If it cancels access to its API, all of those business and users that rely on it are left hanging.

1. However, a simple API can be a useful starting place. For example, some functions of free network service Libre.fm can be used from many music players, because Libre.fm started by cloning the Last.fm API.^{^}