“The most obvious important realities are often the ones that are hardest to see and talk about,” says David Foster Wallace in a famous commencement speech titled “This Is Water,” in which he tells a story about fish discussing water and briefly explains the title: “The most obvious important realities are often the ones that are hardest to see and talk about.” We'll discuss APIs in the first blog post of this series. 

 

APIs are present in every aspect of our digital lives. The concept of an API is so pervasive in computer software that defining it is, ironically, difficult. To add to the confusion, the word Application Programming Interface (API) has been misinterpreted on several occasions. 

 

What is an application programming interface (API)? (Or, to put it another way, a very quick history of APIs) 
One may argue that the concept of an API was developed numerous times separately, with its early history inextricably related to the instantly familiar concept of a subroutine library. To put it another way, it's difficult to talk about APIs without mentioning the (very basic) principles of modular programming and abstraction in computer science. 

 

Herman Goldstine and John von Neumann initially established the concept of a subroutine library in their multi-volume book Planning and Coding of Problems for an Electronic Computing Instrument: 

 

The value of being able to accomplish this [allow the usage of a coded sequence of a problem as a single entity when it happens as part of a larger problem] is enormous. It is very likely to have a significant impact on the ease and efficiency with which a computer automates of the type we are considering may be operated. This option should, above all else, eliminate a bottleneck in the preparation, setup, and coding of problems... We see a well-organized automatic, high-speed institution with a large collection of such subroutines... a "library" of records... in memory. 

 

In essence, Goldstine and von Neumann stated that most programs would have to use existing subroutine libraries in order for computers to reach the capacity anticipated at the time (and would otherwise be “quite dangerous” due to errors and other concerns). Subroutines have been recommended as a critical strategy for speeding up development and reducing errors by reducing the amount of new code that must be created. Unfortunately, the treatise did not provide much in the way of implementation details, preferring instead to focus on a theoretical and high-level discussion of subroutine design and usage. In a well-known presentation titled "A Brief, Opinionated History of the API," Joshua Bloch puts it bluntly: "they were hawking vapourware." 

 

The preliminary procedure devised by Goldstine and von Neumann was a fairly mundane piece of work. It would have had a great deal of operator involvement, and it's hard to picture it ever being a satisfactory technique in practice. 

 

— The Invention of Programming, 1947–51, from Theory to Practice 
Bloch claims that Maurice Wilkes, David Wheeler, and Stanley Gill are the true creators/discoverers of the API in the same presentation. Or, to be more precise, the proto-API, as the name was never used by them. The researchers developed the EDSAC (a pioneering British computer) and published Preparation of Programs for Electronic Digital Computers in 1951, which basically introduced subroutine libraries. After finishing his first "serious program" a few months after giving the original directives, Wilkes would write: "By June 1949, individuals had begun to learn that getting programs right was not so easy..." I was attempting to get my first non-trivial application to run... — from Memoirs of a Computer Pioneer, MIT Press, 1985, p. 145, "The realization came over me with full force that a large part of the remainder of my life was going to be spent in detecting flaws in my own programs." 

Wilkes's fear of making mistakes in his own programs influenced his decision to use subroutines as an organizational principle. 

 

An excerpt from Wilkes' Preparation of Programs for Electronic Digital Computers, perhaps the first API documentation (1951). The document contains the following information: (1) type of subroutine (“closed”), (2) total number of storage places required to hold the subroutine, (3) address number constraints, and (4) approximate execution time. 

In a paper5 about creating remote computer graphics libraries in 1968, the term Application Programming Interface (API) was first used. “It has been satisfactorily proved that computer graphics systems do not require the dedication of a big scale computer for their operation,” the scientists write in the abstract. Computer graphics has followed the wider trends in computing, where "remote access" has become a buzzword." In other words, by the late 1960s, computer scientists had realized that encapsulated and modular computer graphics systems made more sense. (In their work, the authors discuss how to properly interface with such systems.) 

We find the term "Application Programming Interface" used in a variety of contexts (much beyond a basic wrapper around a function) when we search for it in Google Scholar for the years 1970–1995. 

APIs are used to interface with external systems (e.g. storage devices) 
APIs for accessing network functions, as well as a substantial literature on database APIs 
APIs have swiftly grown to mean the communication layer between software abstractions by the early 1990s (local or remote). An API is, according to one definition from 1990, "a set of services available to a programmer for accomplishing specified activities." ⁶ An API, according to another definition from 1993, is "a word for any language and format used by one computer program to help it communicate with another computer program." 

Then there were Web APIs
With the introduction of web APIs, the concept of an API took on new significance. Web APIs are interfaces that connect publicly exposed endpoints of a network, typically via a predefined message-passing system and most commonly accessed using the HTTP protocol, as opposed to the APIs we just discussed—APIs that can be roughly classified as library APIs and must be hardware/software compatible with whichever system they are used by. 

 

Roy Fielding distinguishes between library-based APIs and network-based APIs in his thesis (in which Representational State Transfer8 is introduced): 
The Web's architecture had to change from creating a reference protocol library to creating a network-based API that could extend the Web's desired semantics across many platforms and implementations. 
Because the implementation of the interfaced service was further isolated and black-boxed from the interfacing user, network-based APIs offered a higher level of abstraction than library-based APIs. It didn't matter what kind of machine the service ran on or which language(s) it was written in; all that mattered now was that its services could be accessed via the internet (most commonly by means of an HTTP-based webserver). The most prevalent meaning of the term "API" nowadays is "web API." 

Web APIs were first used for sales and commerce management. 

In 2000, SalesForce released the first online API as part of what is widely considered to be the first SaaS offering. Later that year, eBay launched the eBay API to “openly give the tools that developers need to construct apps based on eBay technology”10 by standardizing how applications interact with eBay (because developers were already hacking eBay's website and using the data in their own applications). 

Then, in the mid-2000s, with the birth of the first social platforms, new APIs appeared that enabled the sharing and embedding of user-generated content: “this was a completely new age for APIs, one that wasn't about money, but about connections.” 

Del.icio.us, an early social media site, introduced a simple API for sharing and labeling internet bookmarks in 2003. REST-like URLs (e.g. http://del.icio.us/tag/[tag name]) gave users to read/write access to del.icio.us bookmarks. 

Flickr released an API in 2004 that allowed users and developers to do things like post images, manage their "favorites" lists, query for users, and search photos. Because Flickr couldn't keep up with demand for their services, they "established the API as a self-service way to deal with business development," which led to "Flickr quickly becom[ing] the image platform of choice for the early blogging and social media movement by allowing users to easily embed their Flickr photos into their blogs and allowing users to easily embed their Flickr photos into their blogs and allowing users to easily embed their Flickr photos into their blogs and allowing users to easily embed their Flickr photos into their blogs and allowing users ¹² The launch of the Flickr API sparked the birth of "BizDev2.0." 

 

... a modest business... wanted an introduction, but I told them that we (Flickr) probably didn't have time to engage with them in any meaningful way, but that they should apply for a Commercial API key and develop something using the API. It's what I refer to as "BizDev 2.0."

You can start building your own Fintech Business with Finage free market data API key.

Build with us today!

Get a Free API key