In 1968, in his seminal essay Systems Esthetics, Jack Burnham wrote:

The specific function of modern didactic art has been to show that art does not reside in material entities, but in relations between people and between people and the components of their environment.

In 2013, this list of relations can be expanded to include those between people and software, as well as those between people and networks. How can art reside within these modern relations, rather than outside of them?

Enter the API.

API is one of those three-letter acronyms (TLAs) which makes only slightly more sense once you know what it stands for. Application Programming Interface; a generic enough term to be applied to many, many pieces of software, lots of which are operating inside of your computer right now. Really the important part of the definition is ‘interface’. I like to think about an API as a bridge which allows one computer program to talk to another computer program.

APIs have a lot of utility, as they can connect disparate programs running on different devices, even if those devices are running completely different operating systems. It’s not much of a stretch to say that any software company would have a set of internal APIs that allow communications between different parts of their software infrastructure. For every public-facing API at Google or Facebook, there are dozens more that are just used inside of the company. There’s a good parallel here to mail services – while a large company might have a mail room that deals with things being delivered to them from the outside world, they also have a lot of internal machinery which allows for mail to be delivered internally. The majority of your day-to-day interaction with social networks, e-mail applications or mobile apps is facilitated by APIs.

If you’ve heard of an API at all, it’s likely the one you’re thinking of is the Twitter API. It is what lets the apps on your phone, or third party Twitter applications communicate with all of the central tweeting machinery at Twitter HQ. Twitter took a risk in the beginning of their business by leaving this API open – they gambled that, by allowing businesses to build products around the main tweeting system, they’d end up with many more projects build on Twitter than they could have built themselves. This ‘open API’ model was so successful that plenty of other companies have since jumped on board and offered open APIs of their own. (Recently, Twitter has severely limited access to its API, to the consternation of the broad community of developers who make use of it).

Because APIs are associated with big companies like Twitter and Facebook and Google, a lot of weight is often attributed to them. The creation of an API can seem almost a reverential act. “They have an API”, we whisper, in hushed tones. Surely they must be hard to build?

As it turns out, you can build simple APIs very… simply. As an example, I spent about an hour writing an API that lets you query for word counts in this article. Go ahead, and try this link:

http://api.blprnt.com/wordcount/API

That number that gets spit out is how many times the word ‘API’ is mentioned on the page (I built it to include comments, so this will change a bit over time). If you’re interested in the extraordinarily simple guts of all of the demo APIs in this post, you can find the code in a GitHub repository.This example shows us that APIs an be built very easily. While you certainly can put a lot of work and weight into an API, making one can also be a quick and expressive way to create bridges and tools between until-now unrelated bodies of content and applications.

This act of bridging, enabled by an API, can be a political one. Josh Begley, a data artist living in New York, has recently created an API which allows access to information on every US drone strike, using data from The Bureau for Investigative Journalism. Updated as new strikes are reported and confirmed, The API allows others access to verified and aggregated data on drone activity. I built a small wrapper API for it which returns just the most recent strike:

http://api.blprnt.com/drones/laststrike

Josh’s API is already a useful tool; journalists can use it to feed stories, apps can use it to display updated counts. It could be used for many conceivable art purposes. A good example is Begley’s own recent project, Dronestream, a Twitter stream of every known US drone attack. Pitch Interactive’s recent ‘Out of Sight, out of Mind‘ project uses the API to update its interactive timeline of drone strikes. Here, through the use of an API, intendedly secret data becomes exposed – open data from the most closed of sources.

Recall that the basic function of an API is to bridge one piece of software to another. In this way, APIs are conduits for the mash-up, long a preferred creative tool for media artists. Instead of producing a single mash-up, though, a functional API makes a permanent link between two applications, one whose pitch and timbre can change as the data themselves are updated.

The API can act as a clear connection, simply relaying data from one place to another. However, it can also operate on these data, shifting modes and meaning as information is requested an relayed. Instead of returning a single number of people killed in a drone strike, what if we returned a list of names? What if those names were extracted from a US zip code, allowing us to think about how media attention and personal perspective would change if these were Americans dying, instead of Afghanis or Pakistanis? More easily, the names could be extracted from our social media feeds. Here is an example API that returns a group of users from my own feed, equal to the number of people killed in the last US drone strike:

http://api.blprnt.com/dronetwitter/blprnt

This is a heavy-handed, quickly drawn example. But it suggests an interesting idea: the conceptual API. A piece of software architecture intended not only to bridge but also to question. The API as a software art mechanism, intended to be consumed not only by humans, but by other pieces of software. (Promisingly, the API also offers a medium in which software artists can work entirely apart from visual esthetic.)

Burnham wrote in 1968 that ‘the significant artist strives to reduce the technical and psychical distance between [their] artistic output and the productive means of society’. In an age of Facebook, Twitter & Google, that productive means consists largely of networked software systems. The API presents a mechanism for artistic work to operate very close to, or in fact to live within these influential systems.