What an API Is and Why It’s Worth Fighting For

On Monday, Google and Oracle will officially enter the next stage in a six-year war over Google’s usage of the Java programming language in constructing the Android operating system. Here, at the United States District Court in San Francisco, where the case began in 2011, a jury will hear arguments as to whether or not Google’s usage of the Java API constitutes fair use. Oracle is seeking a staggering $9.3 billion in damages, or a bit less than twice what it paid in total for Sun Microsystems, the previous owner of the Java name, in 2010.

In building Android back in the 2000s, Google used an implementation of the Java language that had not been officially sanctioned/licensed by Sun Microsystems. But Sun was much more chill about this stuff than Oracle is, so it was not such a big deal. Also: Android was not such a big deal at the time, or really a deal at all. Then, Oracle bought Sun and Java just as Android started to blow up into what it’s become today.

So, noting that the Android Java implementation was not actually licensed and that Google was a fantastically successful, wealthy corporation, Oracle sued. In round one, the same district court that will hear fair use arguments this week found that APIs cannot be copyrighted. Then, in round two, a federal appeals court found that, yes, APIs can totally be copyrighted, but Google’s use of Java might be considered fair use. The appeals court then kicked the case back down to the district court to consider the fair use question. Round three.

To understand what’s going on here, and what the potentially quite grave implications are for software engineering in general, we really need to understand what an API actually is. It’s kind of a tricky, albeit ubiquitous, concept that can mean a lot of things at once (or seem to).

API stands for Application Programming Interface, which probably doesn’t help much. The keyword here is “interface,” which we can imagine as an access point or endpoint that we are going to interact with via our code in some way. There are a few general API uses that each dictate what it is generally we’re going to be interaction with.

The API of Babel

More often than not, an API is something that refers to some outside library or framework. By “outside,” I mean code that I myself have not written, but nonetheless am able to invoke via an API as if I had. This is an everyday part of programming in most any language.

I don’t care how P5 goes about calculating my number behind the scenes, just that it does.

If, for example, I wanted to make some cool interactive graphics for my webpage, I would likely head over to P5.js, which is a JavaScript library based on the Processing programming language. (Note that p5.js is far from the only toolset for making cool visuals on the web, but it’s the one I know pretty well.) Here I can find all sorts of predefined functions—discrete units of code meant to be reused that should ideally perform one and only one specific task—that will make drawing stuff in an HTML document much easier and more intuitive than just writing it all from scratch, which would be a pain in the ass and very error-prone.

To illustrate, if I wanted to come up with a random number that fits a normal or Gaussian distribution, I can just refer to the P5 API, which conveniently has a function called randomGaussian(). And here’s a key point about APIs: I don’t care how P5 goes about calculating my number behind the scenes, just that it does.

(You can look at everything that P5 does here. Keep in mind that this is even a fairly small library—which can be a good thing if you happen to be learning it.)

randomGaussian() won’t tell us how it does its magic for a couple of reasons. First, we don’t need to know. We just need to know what it does, not how it does it. Second, the interface has no idea how it does what it does. It’s almost certainly possible to get that same functionality through alternative implementations. Actually, I claim that any function written in any programming language can be rewritten (re-implemented) in at least one way, but I can’t promise that that one way might not wind up being a really stupid and trivial way.

Anyhow, this disconnect between implementation and function is what makes an interface an interface. It’s a specification, not an implementation.

So, with a standardized interface promising such and such functionality—it’s helpful to imagine an interface as a promise of implementability—I can make my own software (write my own code) that will use interfaces/APIs to access that outside functionality. Again, this is just a routine thing in programming.

APIs for hardware and data

Web APIs are similar but often involve something more than just accessing predefined code. A web API is very often used for accessing the underlying functioning of the website as a whole. Just think of everything that websites do, from social media to stock trading to telling you what to buy. All of this (or most of it) can be accessed via a sort of API known as an endpoint. If I wanted to, say, use Twitter without ever having to see the Twitter homepage, I could do that via the Twitter API and some simple scripting. The API tools Twitter provides makes that really easy to do.

For another example, if I wanted to write a web application to display the weather, it would make the most sense to grab the actual weather data from someone in the actual business of generating weather data, like Weather Underground. Weather Underground happens to have an API that I can use in my code to get Weather Underground weather data. I just have to follow the specifications given for how to actually do that. The idea of a specification is maybe the most important thing underlying the whole notion of an API: how to actually use it.

APIs also provide access to hardware. You don’t even want to know how your computer deals with actual physical hardware, and fortunately you don’t have to. For one example, you might have already heard of OpenGL. This is an open-source API/library that provides a set of functions that can be used by developers to interact with a graphics-processing unit for the purpose of hardware-accelerated graphics rendering. OpenGL is very, very widely used.

The Java API

The Java API is interesting and unique. It’s basically just a Library of Babel of different functions, classes, and data structures that the language provides to programmers to use in their code. It’s huge. Specifications for all of it can be found in the Java documentation, which lists all of these functions and what they do and how to use them. What it doesn’t list is how all of those functions work under the hood—that is, what their implementations are.

We can as programmers just use Java’s own implementations by referencing the Java core API, but we can also use someone else’s implementation as well, or we can even write our own. We just have to make sure that the result meets the same specifications given by the Java API.

This is what Google did, roughly: It used an implementation of the Java API not sanctioned by Oracle/Sun. So, the question is whether or not that constitutes copyright infringement. It should be clearer now as to what is at stake: the fundamental divide between interface and implementation. It so happens that this divide is what much of the open-source software world revolves around, the ability to separate functionality from implementation, to build the same things in new and better ways. Watch Google v Oracle closely.