The History of APIs: From EDSAC Subroutines to AI Tool Calls

By Victor Hoang · Updated Oct 24, 2026

In 1950 Maurice Wilkes, David Wheeler and Stanley Gill issued a report on preparing programs for the EDSAC and using its library of subroutines. A summer-school student later recalled being handed the September issue. Nobody in that room said "API". But the idea was there: you needed to know how to call a routine, not how it worked.

APIs began around 1950 in Cambridge, England, where the EDSAC team shared a library of reusable subroutines so programmers didn't rewrite them. That student's ten-day course had roughly 20 to 24 participants. The phrase "application program interface" appears in print by 1968, in a paper on remote computer graphics. The web API that built today's software industry arrived in 2000-2005. The throughline is a boundary. Each era made the line between two pieces of software more explicit, then crossed a network with it, then made it readable by machines.

Timeline at a Glance

The Subroutine Library (1949-1967)

Code was shared long before anyone called it an interface

Picture the EDSAC room at Cambridge in 1950: a machine with 1,024 17-bit words of memory, paper tape in, a teleprinter out, as the university's own EDSAC statistics page describes it. The same page says the second release of the machine's initial orders, installed in August 1949, included facilities for relocation to ease the use of subroutines, which it calls an important invention by David Wheeler. A subroutine written once could be loaded at any address and called from many programs.

That is the honest precursor, and it's worth keeping apart from what came later. The Cambridge team had reusable code and a documented way to call it, but they didn't have a name for the boundary. Another student recalled that Wheeler spent much of 1950 writing and testing subroutines for everyone else, and a research student, Leonard Dresel, contributed subroutine V1 to the published book. The historian Jeremy Norman's account says the 1950 report was a dittoed document for private distribution, and that the 1951 Addison-Wesley edition, The Preparation of Programs for an Electronic Digital Computer, was the first conventionally published book on software.

The EDSAC statistics page also lists the first book on programming by Wilkes, Wheeler and Gill as published in 1951. What they gave the field was a habit: write a routine once, document its inputs and outputs, and let strangers use it. The longer story of how those routines became languages is in the history of programming languages, and the layers that later hid the machine are in the history of operating systems.

What this means for teams today: The first API was a shelf of tested routines with a manual. If your internal code has no manual, it's a private habit, not a reusable interface.

The Named Interface (1968-1983)

A phrase appears in print, and a network starts to call

In 1968 Ira Cotton of Sperry Rand and Frank Greatorex Jr. of Adams Associates presented "Data structures and techniques for remote computer graphics" at the Fall Joint Computer Conference. The proceedings show the problem they were solving: graphics terminals far from a time-shared central computer. Their argument for building the system to be hardware independent contains the phrase. If the central computer were replaced, they wrote, "a consistent application program interface" could still be maintained.

Read that sentence slowly. The interface was the thing that would outlive the machine. The hardware could change, the application programs wouldn't have to. The paper also describes a library of list-processing subroutines through which the data structure is reachable, so the 1968 "interface" is still a set of callable routines, exactly the EDSAC idea at the scale of a time-sharing center. The paper doesn't claim to coin anything, so treat it as an early printed use, not a birth certificate.

Then the networks arrived. RFC 707, dated 14 January 1976, proposed a "procedure call model" for ARPANET resources: a message type CALL with a procedure name and arguments, and a RETURN with results, on the grounds that programs in a network must sometimes call subroutines in machines other than their own. For the network it grew from, see the history of ARPANET and the history of TCP/IP.

What this means for teams today: The 1968 insight still holds. Define the interface so the implementation behind it can be swapped, and you've bought yourself a free rewrite.

The Remote Call (1984-1999)

Make the network look like a function call

Walk into Xerox's Palo Alto Research Center in the early 1980s and you'd find Andrew Birrell and Bruce Jay Nelson building the Cedar project's remote procedure call facility. Their paper, Implementing Remote Procedure Calls, appeared in ACM Transactions on Computer Systems in February 1984. Its pitch was that procedure calls are a well-understood way to move control and data inside one machine, so extend them across a network. It also notes that RPC had been discussed in the public literature since at least 1976, and that full implementations were rarer than paper designs.

The same paper lists what makes the idea hard: what a call means when machines or links fail, how to pass arguments that contain addresses, and how a caller finds the callee. Those are the problems every later API style inherited. A remote call can fail in ways a local one never does.

The idea spread through standards. Sun Microsystems' RFC 1057, published in June 1988, specified version 2 of its RPC message protocol and recommends Birrell and Nelson's paper as background. The Object Management Group's CORBA specification list shows version 1.0 adopted in August 1991 and version 2.0 in February 1997, extending the same bet to distributed objects. These systems worked inside a company, between teams who agreed on a language and a vendor. They struggled across company lines, which is the problem the next era attacked.

What this means for teams today: Hiding the network behind a function call is convenient and dangerous. Design every cross-service call to fail, retry and time out, because it will.

The Web API Age (2000-2011)

Companies open their front doors to strangers' code

Four documents from 2000 mark the turn. The SOAP 1.1 Note, dated 8 May 2000, was authored by people from DevelopMentor, IBM, Lotus, Microsoft and UserLand and describes an XML-based protocol for exchanging information in a decentralized, distributed environment. The W3C states it made no endorsement of the Note. In the same year, Roy Fielding's UC Irvine dissertation, Architectural Styles and the Design of Network-based Software Architectures, introduced Representational State Transfer, a style derived from how the web itself had been designed, under chair Richard N. Taylor. And companies began to publish their own interfaces. eBay says its first APIs, launched in 2000, were SOAP-based and initially limited to a small number of licensed partners, meant to help sellers manage their businesses at scale.

Amazon went wider. Its press release is filed under 15 July 2002 but carries a 16 July dateline, and it announced the first version of Amazon.com Web Services, free to developers through XML and SOAP. Jeff Bezos called it "a welcome mat for developers," and Tim O'Reilly called it "a significant leap forward in the next-generation programmable internet." This was a product catalog and shopping cart, not the cloud computing business that later took the AWS name; for that story, see the history of cloud computing. The timing also sits inside the shake-out of the dot-com bubble, and the store it opened up is part of the history of e-commerce.

Maps made APIs a public sport. Paul Rademacher says on his own site that in 2005 he reverse-engineered the JavaScript of the then-new Google Maps, scraped Craigslist housing listings, and overlaid them on the map to create HousingMaps, which he calls the first-ever map mashup. On 29 June 2005, a Google blog post by product manager Bret Taylor announced the Google Maps API and pointed to housingmaps.com and chicagocrime.org as examples of what developers could build. The format shifted too: RFC 4627, by Douglas Crockford in July 2006, described JSON as a lightweight, text-based, language-independent data interchange format.

Then came the argument over the word. On 20 October 2008, Fielding wrote that he was frustrated by people calling any HTTP-based interface a REST API, and said of one example: "That is RPC. It screams RPC." His rule was that an API driven by out-of-band information instead of hypertext can't be called RESTful. The label stayed in wide use anyway. If you've ever argued over whether an API is "really REST", this is where it started. The wider web it grew on is in the history of the World Wide Web and the history of HTML and web standards.

What this means for teams today: The winners opened a narrow, useful slice of their product and let outsiders build on it. Pick the one capability partners would pay to wire in, and publish that first.

The Platform Contract (2012-2022)

Security, schemas and courtrooms catch up with success

By 2012 the question was no longer whether to publish an API but how to secure it, describe it and query it. In October 2012 the IETF published RFC 6749, the OAuth 2.0 Authorization Framework, edited by D. Hardt of Microsoft, which lets a third-party application obtain limited access to an HTTP service. The security side is covered in API security.

Facebook's mobile team hit the opposite problem. Lee Byron's 14 September 2015 post says they needed a data-fetching API for the mobile apps, developed GraphQL three years earlier, and that it by then powered hundreds of billions of API calls a day. He wrote that a RESTful service may require multiple round-trips, which are resource-intensive on mobile networks, where GraphQL follows relationships between objects in one request.

Descriptions got a neutral home. On 5 November 2015 the Linux Foundation announced the Open API Initiative, with SmartBear's contributions and founding members 3Scale, Apigee, Capital One, Google, IBM, Intuit, Microsoft, PayPal and Restlet. The OpenAPI Initiative says its specification was originally based on the Swagger Specification, donated by SmartBear Software. A written contract that tools can read is what let documentation, testing and code generation grow around APIs. How teams design for it is in API architecture, and how they wire APIs together is in API integration.

The era closed in court. In Google LLC v. Oracle America, Inc., decided on 5 April 2021, the Supreme Court held that Google's copying of the Java SE API was a fair use as a matter of law. The syllabus notes that Google copied about 11,500 lines of declaring code, which it describes as 0.4 percent of an API of 2.86 million lines. The holding covered the copying at issue, not every use of someone else's API, but it matters to anyone who builds on an interface they didn't write.

What this means for teams today: Auth, a machine-readable spec and a clear change policy aren't extras. They're the product. If you want to see how API-led distribution turns into a growth model, read API-first product growth.

Machines as Callers (2023-present)

The newest API consumer isn't a developer at all

For most of this history the caller was a programmer who read the docs. In June 2023 that changed in a small way. Simon Willison's summary of OpenAI's 13 June 2023 announcement explains that you can send a JSON schema defining one or more functions to GPT-3.5 and GPT-4, and the model may return a blob of JSON describing a function it wants called; your code then executes it. The model never calls the API itself. It reads a description, picks a function and fills in the arguments.

Anthropic made tool use generally available on 30 May 2024, describing it as letting Claude interact with external tools and APIs. On 25 November 2024 it open-sourced the Model Context Protocol, a new standard for connecting AI assistants to the systems where data lives, including content repositories, business tools and development environments. We'd read the pattern as a return of the RPC bargain with one difference: the interface description now has to persuade a model, not only inform a human. Clear names, narrow functions and honest error messages matter more when the reader can't ask a colleague.

What this means for teams today: Treat your OpenAPI or tool schema as the instruction manual for a new, literal-minded user. If an agent can't use it without guessing, neither can a new hire.

Key People

Key Facts

Key Facts: API History

• The 1950 Cambridge report on EDSAC's subroutine library was a dittoed document for private distribution, per the Jeremy Norman history.
• A 1968 conference paper wrote of keeping "a consistent application program interface" if hardware were replaced, per the proceedings.
• Remote procedure calls had been discussed in the public literature since at least 1976, according to Birrell and Nelson.
• Amazon.com Web Services launched in 2002 free of charge, via XML and SOAP, per Amazon's release.
• Google copied about 11,500 lines of declaring code, 0.4 percent of 2.86 million lines, per the Supreme Court syllabus.
• Facebook's GraphQL powered hundreds of billions of API calls a day by 2015, per Facebook Engineering.

The Pattern Behind the History

Over seventy years, the history of APIs repeats four moves. We call it the Contract Loop. It's our own synthesis of the sources above, not a published study.

1. Share. Someone writes a routine worth reusing: Wheeler's subroutines, a graphics library, a catalog search.
2. Name. The boundary gets a manual, then a name and a spec: the 1950 report, "application program interface", SOAP-era message contracts, OpenAPI.
3. Cross. The boundary moves outward, from one program to a network to a company line to the public: RPC, SOAP, Amazon, Google Maps.
4. Contest. Once many people depend on the contract, the owner and the users disagree about its terms, in specifications, in naming fights over REST, in OAuth, and in Google v. Oracle. The dispute produces the next, stricter contract.

What It Teaches Teams Today

• The interface outlives the implementation. The 1968 authors wanted the application program interface to survive a hardware swap. Your API should survive a rewrite.
• Publish a narrow slice first. eBay began with approved partners, Amazon with a catalog and a cart. Neither opened everything at once.
• Write the contract down in a form tools can read. A schema is documentation, test input and, now, an agent's instruction manual.
• Plan for the dispute. Versioning, deprecation notices and licence terms are where API relationships break. Settle them before your first outside user.
• Keep reading the foundations. APIs sit on top of the network protocols in the history of the Internet, and the search side of the story is in the history of search engines.

Keep reading

• Internet timeline: the dated milestones from telegraph lines to AI agents.
• API architecture: how to structure an API for scale and change.
• API integration: how systems are wired together in practice.
• API-first product growth: when an API becomes the distribution channel.

APIs started as a shelf of tested routines and a manual, and every era since has widened the audience for the manual. The callers changed from Cambridge students to partners to the public to models. The question stayed the same: what exactly are you promising the next person who calls?