To work and live in today's digital world, we are unquestionably dependent on interconnected applications. These applications might be massive and highly complex, but they're also constructed from reusable building blocks, which we call an Application Programming Interface—the API.
API adoption is on the rise across all industries. However, APIs aren't new. They came about from the natural evolution of writing computer software. Understanding the origin and evolution of APIs is foundational to your ability to thrive as a software architect, application developer or IT decision-maker.
In this two-part blog post series, we'll trace the evolution of APIs from early computing up through the early stages of the internet. In this post, we will look at APIs during the pre-internet computing era as well as during the PC era.
APIs are pieces of software that allow computer programs running on the same computer or on different computers connected over a network to communicate with one another.
An API connects a calling application (the client) and a called application (the service). That "service" might be a web server, a database server or even a monolithic application. The client is unconcerned with the details of the service's implementation. Instead, the client simply needs to know how to communicate with the API.
The client sends a request to the API endpoint. The API may authenticate the request and perform some additional processing, and then it passes the request to the service. The service performs some operation—often this is fetching or manipulating data—and then returns a response to the API, which sends a response back to the client.
Figure: A Simple API Request-Response Scenario
APIs have a standard feature known as a defined interface. This interface includes:
The client can only interact with the API via this interface, typically described according to a standard specification, such as WSDL, RAML or OAS.
An API encapsulates the implementation of the service underneath, meaning developers consuming an API don't need to know its inner workings. A developer doesn't know if that API is calling other APIs behind the scenes or how data is being used internally.
Because of this encapsulation, the implementation of an API is language-independent, such that the choice of implementation language should not affect the consumer's ability to invoke the API.
APIs have built-in security checks—protections like firewalls or an API gateway or encryption (such as SSL or TLS) for data in transit. APIs may implement input validation or require authentication for access.
The use of APIs brings several benefits. One clear benefit is reduced time and effort in software development. Developers can use services and data already available, building new features on top. Language, framework and platform independence make it easier for anyone to build APIs for everyone.
API reuse allows developers to offload certain repetitive functions to third-party service providers. For example, user authentication can be achieved by using APIs from Google or Facebook. E-commerce applications can offload payment flows by using APIs from PayPal or Stripe. Leveraging third-party technologies allow businesses to focus on their core product areas, decreasing their time to market.
Some companies develop APIs to monetize them, making them available to paying customers. Other companies make their APIs available to increase brand awareness.
The benefits of developing and using APIs seem clear, but how did the modern computing world stumble upon APIs to begin with? The roots of the API predate the modern personal computer era, stretching back to the early days of computing.
The early days of computing saw the progression from large fill-the-whole-run mainframe computers of the 1960s to the PC era of the early 1980s. The evolution of the API followed the evolution of computer programming.
In the 1960s and 1970s, computer programs were large, monolithic documents of code that you would key into a magnetic disk. As operating systems evolved, so did programming languages. From the earliest programming languages, computing began to see the use of subroutines and functions.
Subroutines broke up code into manageable chunks, and those chunks could be called from the main program. This led to collaboration, as programmers could work together on a program, calling subroutines written by other programmers. Soon after, we had functions, which could accept one or more arguments (input data) and produce a predictable output.
Operating systems began to expose scripting capabilities, which system administrators could use to automate common workflows. Though not full-fledged programming languages, scripting languages had all the elements of high-level programming: looping, conditional branching and user input validation.
With the PC era of the early 1980s and the proliferation of high-level programming languages, commercial software development began to emerge, and the Windows operating system came onto the scene.
Windows was one of the forerunners of the modern, modularized, reusable programming paradigm. It introduced the use of the dynamic link library (DLL) that encapsulated different program modules. Windows-hosted applications could load or unload these DLLs into memory as they ran.
The broader adoption of object-oriented programming (OOP) in the latter part of the century helped developers build genuinely reusable components. Programming languages emerged with libraries for interacting with system hardware. Development teams would create class libraries that they could use in subsequent projects.
Alongside the rise of OOP, we saw growing popularity in network-capable operating systems. Internally, companies were beginning to create network-centric applications using the client-server model.
In client-server computing, a server would run in a corporate network. At the same time, user workstations (the clients) would connect to the server over TCP/IP or NetBIOS. This approach led to two new development technologies for client-server programming: Component Object Model (COM) and Distributed COM (DCOM).
COM was a specification that enabled inter-process communication (IPC) between software components in the same machine. DCOM, on the other hand, enabled COM components to run across different devices in a network. With DCOM, it was possible to write distributed applications communicating across machine boundaries.
In this blog, we started by looking at common features for APIs and why they're so integral to software development. We also traced the evolution of APIs during the early computing age. Stay tuned for the next blog post in our series, where we will discuss the evolution of APIs in the early internet age.
This is part of a 3-part series on APIs, sustainability, and climate change. Check out part 1 on managing a greener API lifecycle, and part 2 on ways to embed and innovate on top of third-party APIs to make greener products. In this final part
The API management space is changing - fast. In the past couple of years alone, we've seen huge changes in the deployment patterns that our customers are adopting. In the past, when the use cases were fairly simple, organizations would deploy an
In our last blog post , we discussed the evolution of APIs from early computing to the PC era. In this post, we'll discuss the evolution of APIs in the early internet age. Along the way, we'll touch upon associated core technologies such as eXtens
The challenges of an acquisition frequently appear in a number of critical areas, especially when dealing with a platform as important as Kafka: API Instability and Change : Merged entities frequently rationalize or re-architect their services, whic
Everyone's telling you to innovate faster with AI. Move quicker. Ship more features. Deploy more agents. But before we sprint headlong into the AI revolution, we need to have a proper dollars-and-cents conversation that most companies are avoiding.
Introduction: It’s a great report for us here at Kong, and it further validates the changes happening in the larger market The 2025 Gartner Magic Quadrant for API Management report was a great one for us here at Kong. We continue to move “up and to
The challenge: A disconnected world Consider the typical enterprise architecture in a relatively mature organization, an API management layer defines and deploys services to an API gateway, an Identity Provider (IDP) manages human user identities, a