I was asked to speak about APIs at WebWise 2014, in Baltimore, this year. Specifically I was asked to lead a workshop about why cultural heritage institutions would even want an API and how they might go about justifying its existing before, during and after its creation. As such it was not a technical talk, per se. Or at least not nearly as technical as it might have been.

I didn't have notes for this talk so the slides are included below, as-is. They make a certain amount of sense without a spoken dialogue but I am posting them here mostly to have a slightly more permanent record than whatever the nightmare of backwards incompaptible presentation software affords. Apologies in advance for including 70 slides on one page.

I've been talking about a lot lately is the idea of how individuals inside an organization deploy outside the master narrative. This is a subject larger than cultural heritage institutions or APIs but the nice thing about APIs is that they provide a kind of sanctioned territory for people to explore those ideas. We usually talk about APIs in the service of third parties but they are just as able to be used by people inside the hula hoop and that's important because implicit in publishing an API is the idea that new interfaces will be imagined.

This is not true of all APIs since many exist solely to automate rigidly defined processes but to the extent that an organization offers up a more exploratory interface to their service they can't not also accept that people will use it to reimagine the service itself.

The other thing about APIs is that they are just another step in the same abstraction that has defined computer programming from day one: That all computer programming is about what you can and can not take for granted.

Last fall, Seb and I taught a class about Museums and the Network at Pratt. It became clear during the first class that most of the students were not programmers but that many of them wanted to learn enough to not be caught completely unawares by it. So we re-jiggered things a bit and the second class was devoted not so much to describing variables and scope and functions and the usual shop-talk around programming as it was to trying to explain the principles that span all the gibberish and bickering that most people hear when forced to listen to a group of computer nerds. I started by declaring that That all computer programming is about what you can and can not take for granted. Which sounds grandiose and important and more often than not demands performing the kind of mental gymnastics required to wrap your head around Alan Turing and binary state machines.

Another way of saying the same thing is to ask: Do you make your own pasta by hand or do you use it ready-made from a box? Because most of what people know about cooking — inputs, outputs, instructions, environmental conditions, time — can be directly applied to computer programming. Most important of all is the idea that language is culture is as true in programming as it is in the body politic as it is in cooking.

Even if people have trouble believing this to be true at a societal level it's difficult to ignore the reality when confronted by a stack of cookbooks. Consider the recipes for Boeuf Bourguignonne as written down by Julia Child, Maureen Evans and Elizabeth David. They're all making the same thing, right?

Which is why we made Larry Wall's 1999 Perl, the first postmodern computer language required reading for the class. Which is why APIs.