What is the Genuine Value of APIs

This is the first post in our series, “Getting APIs on the Blockchain”.

There is a famous David Foster Wallace commencement speech titled “This is Water” where he offers a little parable of fish discussing water and briefly explicates the title with: “The most obvious important realities are often the ones that are hardest to see and talk about.” In the first blog post of this series, we will be talking about APIs.¹

APIs are everywhere — they permeate our digital world. The concept of an API is so inescapable in computer software that it’s ironically difficult to appropriately define it. To further this difficulty, the term Application Programming Interface (API) has superseded its original meaning on quite a few occasions.

What is an API? (Or: a very brief history of APIs)

One could argue that the concept of an API was independently discovered several times, its early history being intrinsically linked to the instantly ubiquitous concept of a subroutine library. That is, it’s difficult to discuss APIs separately from the (very fundamental) concepts of modular programming and abstraction in computer science.

This idea of a subroutine library was first formalized in 1948 by Herman Goldstine and John von Neumann in their widely-circulated, multi-volume treatise Planning and Coding of Problems for an Electronic Computing Instrument²:

The importance of being able to do this [permit the use of a coded sequence of a problem as a single entity, when that problem occurs as part of a more complicated one] is very great. It is likely to have a decisive influence on the ease and the efficiency with which a computing automat of the type that we contemplate will be operable. This possibility should, more than anything else, remove a bottleneck at the preparing, setting up, and coding of problems … we envisage that properly organized automatic, high speed establishment will include an extensive collection of such subroutines… I.e. a “library” of records … in memory.

Essentially, Goldstine and von Neumann argued that most programs would have to utilize existing subroutine libraries in order for computers to grow to the capacity envisaged at the time (and would otherwise, due to errors and other issues, “be quite dangerous”). Subroutines were proposed as an essential method for speeding up development and decreasing errors by way of decreasing the amount of new code to be written. The treatise, unfortunately, didn’t offer much in the way of implementation specifics, instead opting for more of a theoretical and high-level description of subroutine construction and use. In a well-known presentation delivered by Joshua Bloch entitled “A Brief, Opinionated History of the API,” Bloch bluntly puts it: “they were peddling vapourware”.³

Goldstine and von Neumann’s preparatory routine … was a surprisingly pedestrian piece of work. It would have required extensive operator intervention and it is difficult to imagine that it would have ever been a satisfactory procedure in practice.

— from Theory to Practice: The Invention of Programming, 1947–51

That is why, in that same presentation, Bloch opines that Maurice Wilkes, David Wheeler, and Stanley Gill are the true creators/discoverers of the API. Or — more accurately — the proto-API, given that the term was never actually used by them. The researchers built the EDSAC (an early British computer) and later authored Preparation of Programs for Electronic Digital Computers in 1951, in which subroutine libraries were effectively introduced.⁴ A few months after writing the initial orders and upon completing his first “real program”, Wilkes would write:

By June 1949 people had begun to realize that it was not so easy to get programs right … I was trying to get working my first non-trivial program … the realization came over me with full force that a good part of the remainder of my life was going to be spent in finding errors in my own programs.

— from Memoirs of a Computer Pioneer, MIT Press, 1985, p. 145

Wilkes’ fear of errors in his own programs largely inspired his development of subroutines as an organizing principle.

The first time the term Application Programming Interface (API) was actually used was in 1968, in a paper⁵ about designing remote computer graphics libraries. In the abstract, the authors state: “it has been adequately demonstrated that computer graphics systems need not require the dedication of a large scale computer for their operation. Computer graphics has followed the trends of computing in general, where remote access … has become a key phrase”. That is, the authors note that (by the late 1960s) it became clear to computer scientists that encapsulated and modular computer graphics systems made more sense. (The authors address how to properly interface with such systems in their paper.)

When searching for “Application Programming Interface” in Google Scholar for the years 1970–1995, we find the term used in numerous contexts (far beyond a simple wrapper for a subroutine):

• APIs for interacting with external systems (e.g. storage devices)
• APIs for accessing network functions
• nd, an extensive literature on APIs for databases

By the early 1990s, APIs quickly evolved to very generally denote the communication layer between software abstractions (local or remote). Indeed, one definition from 1990 states an API is “a set of services available to a programmer for performing certain tasks”.⁶ Another from 1993 states an API is “a term for any language and format used by one computer program to help it communicate with another program”.⁷

The notion of an API expanded its meaning yet again with the dawn of web APIs. As opposed to what we just previously discussed—APIs that can be roughly categorized as library APIs and needing to be hardware/software compatible with whichever system they are used by — 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.

In his thesis (in which Representational State Transfer⁸ is introduced), Roy Fielding distinguishes between library-based APIs and network-based APIs:

The design of the Web had to shift from the development of a reference protocol library to the development of a network-based API, extending the desired semantics of the Web across multiple platforms and implementations.

Basically, network-based APIs offered a further abstraction from library-based APIs, because the implementation of the interfaced service was further abstracted and black-boxed from the interfacing user. It didn’t matter what kind of machine the service operated on or which language(s) it was implemented in, it now only mattered that it’s services were accessible via the web (most commonly by means of an HTTP-based web server). Today, a web API is the most common connotation of “API”.

The earliest uses of web APIs were for sales and commerce management.⁹ SalesForce launched the first web API in 2000 under the umbrella of arguably the first SaaS product. Later in the same year, eBay launched the eBay API in order to “openly provide the tools that developers need to create applications based on eBay technology”¹⁰ by way of standardizing how applications would interface with eBay (since developers were already hacking away at eBay’s website and using the data in their own applications).

In 2003, del.icio.us — an early social media site — offered users a simple API for sharing and tagging their internet bookmarks. Users had read/write access to bookmarks on del.icio.us via REST-like urls (e.g. http://del.icio.us/tag/[tag name]).

In 2004, Flickr launched their API which allowed users/developers to, among other things: upload images, manage their “favourites” lists, query for users, and search photos. The launch of the API was motivated by the fact that Flickr couldn’t keep up with demands for their services and “established the API as a self-service way to deal with business development” which ultimately resulted in “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 social network streams”.¹² The launch of the Flickr API was the catalyst for “BizDev2.0”.

… a small startup … wanted an introduction, but I said we (that is, Flickr) probably didn’t have the space on our schedules to engage with them in any meaningful way, but that they should feel free to apply for a Commercial API key and build something off the API. “BizDev 2.0” I call it.

— Caterina Fake, co-founder of Flickr

In 2006, Facebook, Twitter, and Google followed suit, launching their own APIs in hopes of encouraging BizDev2.0 on their respective platforms.

And then came cloud computing …

Amazon S3 is storage for the Internet. It’s designed to make web-scale computing easier for developers … It gives any developer access to the same highly scalable, reliable, fast, inexpensive data storage infrastructure that Amazon uses to run its own global network of web sites. The service aims to maximize benefits of scale and to pass those benefits on to developers.

— from the AWS press release (March 14, 2006)

The capability of web APIs did a quantum leap with the introduction of Amazon Web Services (AWS). AWS and its three initial offerings (S3, SQS, and EC2)¹² launched in mid 2006. This was the dawn of cloud computing. Amazon Web Services succeeded in abstracting away much of the day-to-day work of software engineers, making essential and complex services (like computing, storage, networking, and deployment) available via simple web API calls (albeit for a fee). With AWS, a developer could set up and deploy a server (for example) in minutes, something that would have previously taken days or weeks. Cloud computing quickly revolutionized the way developers build applications on the web.

Where are we now?

The role of software engineering has changed quite a bit, and coding isn’t even a huge part of it anymore … You know how in the old days people used to write in assembly code? And then we abstracted upon that, so more people started writing C++? And then people started abstracting upon that, and writing Java. And now we have Python, and we’ve abstracted upon that too… Now programmers are gluing pieces together through API endpoints and frameworks. Most top apps [these days] support so much functionality, that it’s pretty much beyond the knowledge of a single person to handle all of those anymore.

— Ex-Facebook/Ex-Google tech lead and famous YouTuber, TechLead¹³

Nowadays we take for granted that software applications can and do communicate with each other with relative ease via each other’s APIs. Developers can now build complex applications at a rate never before seen. Integrating existing services to their applications through APIs has allowed developers to build increasingly complex and capable applications, which has led to the rise of giant Web services and mobile applications. Because of this, APIs are often referred to as the glue that holds the digital world together.

Providing in-demand APIs has become quite the lucrative business, by way of businesses monetizing their data and services. As a result**, the concept of an API has transcended its meaning yet again.** The term no longer refers to the technical implementation of an interface, but to a full-fledged product that often includes the service it wraps.¹⁵ Global enterprises that provide APIs generate 25% of their organizational revenue from APIs on average.¹⁶ Companies such as Salesforce, Expedia, and eBay have reported to generate the majority of their revenue through APIs¹⁷, and even entrenched industries such as banking are expected to be disrupted by this movement.¹⁸ We are now at the cusp of fully API-centric business models.¹⁹

As APIs continue to encapsulate increasingly higher and higher abstractions of software services, the meaning of “API” will continue to evolve.

What’s to come with the rest of this blog series?

You might be wondering at this point when are we to address topics suggested by the second half of our series title (“… on the Blockchain”). Well, there is a very critical problem we introduce in our next blog post called “The API Connectivity Problem” which will take the remainder of this series to fully explicate and map out a solution to.

Briefly, existing APIs are not natively compatible with decentralized applications — a blockchain network is essentially walled-off from communicating with these systems and protocols that permeate the rest of our digital world. How do we bring these interfaces onto the blockchain? How do we get blockchain applications to safely interact with the richness offered by existing APIs? Stay tuned for the rest of our series!

Footnotes [1]: Of course, Wallace’s speech was tender and moving whereas we’ll just be discussing APIs (for now), so please excuse the abrupt change in tone… [2]: Goldstine, Herman Heine, John Von Neumann, and John Von Neumann. “Planning and coding of problems for an electronic computing instrument.” (1947). [3]: https://www.infoq.com/presentations/history-api/ [4]: Wheeler, Maurice V., and Stanley Gill. The preparation of programs for an electronic digital computer: with special reference to the EDSAC and the use of a library of subroutines. Addison-Wesley, 1951. [5]: Cotton, Ira W., and Frank S. Greatorex Jr. “Data structures and techniques for remote computer graphics.” Proceedings of the December 9–11, 1968, fall joint computer conference, part I. 1968. [6]: Malamud, Carl. Analyzing Novell Networks. John Wiley & Sons, Inc., 1991. [7]: Bardige, Stephen I. “A Glossary of Computer Terms and Definitions.” Judges J. 32 (1993): 72. [8]: REST is a very common software architecture style that defines a set of constraints to be used for creating web services. [9]: https://history.apievangelist.com/ [10]: https://www.ecommercetimes.com/story/5403.html [11]: https://history.apievangelist.com/#Social [11]: https://history.apievangelist.com/#Flickr [12]: S3, SQS, and EC2 are Amazon’s storage, queue, and compute services offered remotely via API (also known as “cloud computing services”). [13]: [14]: MuleSoft, “Connectivity benchmark report,” 2020. [15]: Collins, G., and D. Sisk. “API economy: From systems to business services.” TechTrends (2015). [16]: MuleSoft, “Connectivity benchmark report,” 2019. [17]: Iyer, Bala, and Mohan Subramaniam. “The strategic value of apis.” Harvard Business Review 1.7 (2015): 2015. [18]: R. Narain, A. Merrill, and E. Lesser, “Evolution of the API economy: Adopting new business models to drive future innovation,” IBM Institute for Business Value, 2016. [19]: Capgemini, Efma. “World FinTech Report 2019.” (2019).

Previously published here.