However, in spite of the obvious similarities with the contemporary use of interfaces, it is difficult to tell whether such early use of the term had any influence on how we employ APIs today. Regardless of this, what can be concluded without question is that the notion of interfaces as the means of achieving some form of abstraction has been present since the early days of computer science. Recognizing this is extremely important as it's clear evidence that APIs have and will continue to evolve. This will be the case even more so as faster, more efficient, and more compact hardware infrastructure, application communication protocols, and architecture paradigms are introduced to the industry.
This is one of the main reasons that this book has, to the extent possible, decoupled itself from just one API architectural style (for example, REST) and rather it focuses on the bigger picture, such as approaches, concepts, technical capabilities, and patterns that may also apply in the future, beyond APIs as we know them today.
Modern APIs are broadly considered to be an evolution of the Remote Procedure Call (RPC) protocol. Although research for the protocol started in the 1970s, it wasn't until the late 1980s, when Sun Microsystems (now part of Oracle Corporation) first released its UNIX-based RPC implementation, that the protocol gained wide popularity and adoption.
Please refer to the following article for further details: https://en.wikipedia.org/wiki/Remote_procedure_call#History_and_origins
The Open Network Computing (ONC) RPC, also referred to as Sun's RPC, had many of the characteristics expected of modern APIs:
- It made use of the External Data Representation (XDR) standard to define an interface that both server and client applications should comply with.
- It made use of XDR as the means to serialize and deserialize data over the wire (basically request and response messages).
- It made use of the still-widespread Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) as transport.
Figure 6.1: Modern APIs as perceived today
As illustrated in preceding diagram, modern APIs, such as RPC, also consist of a client application (the consumer of the API), a server (the producer of the API) and an interface definition document detailing, in technical terms, all the details of an interface, such as the actions/methods/resources supported and data inputs and outputs.
However, ONC RPC wasn't the only popular RPC implementation. The following diagram illustrates in chronological order the interface protocols and standards that followed and still apply today.
As can be seen, within five years of its inception, the Open Software Foundation (OSF), a non-profit organization originally consisting of Apollo Computer, Groupe Bull, Digital Equipment Corporation, Hewlett-Packard, IBM, Nixdorf Computer, and Siemens AG, (referred to as the Gang of Seven), released its own implementation of RPC called the Distributed Computing Environment (DCE) RPC.
Note that in February 1996, the OSF merged with X/Open to become The Open Group.
Figure 6.2: Application interfaces protocols and standards evolving through time
Although, at a conceptual level, DCE RPC shared many of the characteristics of ONC RPC, in actual practice there were many notable differences. For example, the former made use of an XDR standard as the means to define public interfaces and also to serialize and deserialize data over the network. The latter made use of its own interface definition language (IDL) and a network data representation (NDR) specification to serialize data into octet streams (a process known as marshaling) and then deserialize it (a process known as demarshaling).
Another difference was that DCE RPC did not limit the number of parameters on a call; in ONC RPC, on the other hand, calls were limited to one input and one output parameter.
All of the interface protocols and standards are described in detail in the following article:
https://www.soa4u.co.uk/2019/02/a-brief-look-at-evolution-of-interface.html
![]()
One important characteristic that both DCE and ONC RPC protocols had in common, though, was the fact that neither were based on the object-oriented programming model, which was increasingly gaining popularity in the early 1990s.
The first RPC-based protocol natively supporting the object-oriented programming model was the Common Object Request Broker Architecture (CORBA), created by the Object Management Group (OMG) consortium. CORBA, just like other RPC systems, followed a client-server architecture, with the major difference being that instead of serializing/deserializing flat data over the network, it adopted the Internet InterORB Protocol (IIOP) as a messaging protocol to transfer objects over a TCP/IP transport.
The Distributed Component Object Model (DCOM) was perhaps the second RPC-based protocol supporting the object-oriented programming model. DCOM was created by and remains the property of Microsoft. However of interest is the fact that DCOM made heavy use of Microsoft RPC (MSRPC), which is nothing but a modified version of DCE RPC but was originally created to support a client/server model in the Windows NT operating system.
It's worth noting that with the popularity of these proprietary protocols also came the emergence of a new set of tools in support of enterprise application integration (EAI). EAI tools made use of these protocols to enable the integration of different applications that could not otherwise talk to each other. Refer to Chapter 2, The Evolution of API Platforms, for a comprehensive overview of how EAI evolved into the modern platforms...
