The rise of the modern API
Ever since the dawn of the Internet, people have struggled with how to get one computer to talk to another. Early business systems had no provision for such interactions. They were entirely closed— worlds unto themselves.
As enterprises set up early networks, the question of how to get applications to interact with each other became a pressing business concern, and led to the introduction of Remote Procedure Calls (RPCs). A client computer might directly interact with the program running on a server or host by calling procedures (or subroutines, methods, etc.) over the network.
As long as every host system had its own proprietary architecture, operating system and programming environments, however, such RPCs were rarely practical. As those systems matured, a level of standardization became more commonplace, and the Application Programming Interface (API) was born.
Early APIs exposed RPC interactions, and the fact that we were able to define a software interface allowed us to abstract the underlying code—thus simplifying the software on the client side and providing some measure of flexibility.
Flexibility, however, is a relative term. For many years, virtually any change in the code on the server required a commensurate update on each client—a problem we now call tight coupling. Companies were able to live with tightly coupled client/server applications. After all, they had little choice.
That is, until the Internet came along.
Thanks to simple protocols like HTTP and HTML, browser interactions with web servers were loosely coupled. Any browser worked with any Web page on any Web server and wouldn’t break when someone updated the page—more or less.
But what about application-to-application integration? How do we make those interactions as loosely coupled as the Web?
The answer: Web services. Take the suddenly popular eXtensible Markup Language (XML) as a basis, combine it with the hard-won lessons of interface publication and discovery from the Common Object Request Broker Architecture (CORBA®), and hammer out standard protocols for contracting software interfaces—now called services—and the formats of the messages they exchange.
Oh, and don’t forget publication and discovery of the services, which require more than an XML-based standard. We actually need architecture. And lo, Service-Oriented Architecture (SOA) was born, like a phoenix from the flames of CORBA.
The service contracts that defined Web services provided looser coupling as compared to the earlier generation of client/server APIs but required traditional middleware in order to support the data transformation and content-based routing at a scale that enterprises required to implement SOA in practice.
These Enterprise Service Buses (ESBs) were an important part of the early SOA story to be sure. But the combination of ESBs and Web services proved difficult to implement in practice—and with the advent of cloud computing, this first-generation SOA story became ripe for further innovation.
Today, the principles of SOA have become a part of the fabric of enterprise distributed computing, and by navigating the gauntlet of Web services, we have reinvented the API for today’s cloud and mobile-centric world.
Read the entire white paper at https://www.softwareag.com/corporate/images/sec_SAG_API_Management_4PG_WP_Oct15_tcm16-134199.pdf (registration required).
Copyright © Intellyx LLC. Software AG is an Intellyx client. Intellyx retains full editorial control over the content of this paper.
