To work and live in today's digital world, we are unquestionably dependent on [interconnected applications](https://hbr.org/2021/04/apis-arent-just-for-tech-companies)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](https://www.programmableweb.com/news/apis-show-faster-growth-rate-2019-previous-years/research/2019/07/17)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](https://en.wikipedia.org/wiki/Web_Services_Description_Language)WSDL, [RAML](https://raml.org)RAML or [OAS](https://spec.openapis.org/oas/latest.html)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](https://docs.microsoft.com/en-us/troubleshoot/windows-client/deployment/dynamic-link-library)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](https://en.wikipedia.org/wiki/Inter-process_communication)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](https://konghq.com/blog/evolution-apis-rpc-soap-xml-part-2)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
[](https://konghq.com/blog/enterprise/the-environmental-impact-of-common-architecture-patterns)
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
[](https://konghq.com/blog/enterprise/kong-vs-apigee-flexibility)
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
[](https://konghq.com/blog/enterprise/evolution-apis-rpc-soap-xml-part-2)
Imagine 47 million requests hitting your platform last month. Can you prove who made each one—and invoice with confidence? If that question tightens your stomach, you're not alone. Metered billing for APIs promises fair, transparent pricing that s
[](https://konghq.com/blog/enterprise/guide-to-metered-billing-for-apis)
In large organizations, platform architecture tends to be more historical artifact than intentional design. At the foundation of the stack sit monoliths that predate modern API standards; many of them are too risky or too costly to decommission full
[](https://konghq.com/blog/enterprise/api-composition-packaging)
This is the pitch to the board and the C-suite. It must be brutally concise, focused entirely on your business outcomes, not the technology. If the first page doesn't articulate value, the strategy dies. Why? It immediately frames the initiative in
[](https://konghq.com/blog/enterprise/enterprise-api-strategy-legacy-modernization)
The first pillar is enablement. Developers need tools that reduce friction when building AI-powered applications and agents. This means providing: Native MCP support for connecting agents to enterprise tools and data sources SDKs and frameworks op
[](https://konghq.com/blog/enterprise/agentic-ai-developer-platform)