An Overview of How API Architectures have Evolved

Dec 3, 2021
6 min read

API (Application Program Interface) – one of the most vital technologies that enable smooth communication between computer applications, has come into its own since the last couple of decades. The penetration of the Internet in addition to the developments in the field of information technology has brought about a major revolution in the way we interact with web-based applications. Over time, as businesses continue to increase their online presence, the necessity for data-driven software becomes even more prominent. Here’s where API plays a significant role.

What is an API?

An efficient software-to-software interface that helps web applications exchange data among themselves, an API has proved to be one of the best ways to lower operational costs by simplifying software development. They work on the premise of request-response – an API has a defined set of rules explaining the way applications communicate with each other. It is basically an intermediary interface between the web server and an application that helps in processing data transfer between systems.

In layman parlance, here’s how it works:

API functionality
How an API Works

Booking an air ticket through a travel agency is one of the best examples demonstrating the working of an API.

What is API Architecture?

An API architecture or format is one through which APIs are able to function. It is a set of structures, rules, and restraints governing API operations.

Years earlier, businesses deployed service-oriented architectures (SOA) to connect internal systems; however, SOAs were not the most effective way beyond the enterprise level. To that end, special API-based architectures were designed for quicker development and reduced governance.

Today, with an increasing number of mobile applications and a massive digital transformation, the need for a set of protocols that can be modified as per requirement and deliver instant services to customers has substantially increased.

There are 4 major types of API architectures that are fairly well-known – SOAP (Simple Object Access Protocol), REST (Representational State Transfer), RPC (Remote Procedural Call), and GraphQL. A fifth one, gRPC is currently doing the rounds and is touted to be a part of most future API scenarios.

A Look into the History of API Architecture, and its Evolution over the Years

Before the Internet protocol suite (TCP/IP) was developed, in the 1970s, software applications were more like a collection of subroutines performing specific tasks. APIs did exist even then, only, in the form of simple protocols supporting distributed computing networks spanning a small area. APIs evolved since the advent of the World Wide Web and continue to dominate the Internet today.

Tracing the history of web-based APIs, the first one in this regard could be Salesforce’s web-based sales automation tool launched in the late 1990s – this application, in fact, is said to have kickstarted the SaaS (Software as a Service) revolution. With the absence of a proper framework in place, businesses adopted service-oriented architectures (SOA), as mentioned before. Conventional SOA however, was restricted to an organizational level. The need for efficient protocols continued to grow and the first major effort in this area manifested in the form of CORBA (Common Object Request Broker Architecture) launched in 1991.

CORBA basically separated codes running on two different machines (client and server) and focused on making remote process calls from the client to the server by means of a code-connecting proxy. The client then waited for a response and ran his code to translate the same. Although this worked for a while, the need for updates quickly became apparent, which further led to the advent of SOAP.

SOAP was invented in 1998, enabling clients to invoke web services and obtain responses on different platforms and languages. REST followed soon after, in 2000, after which businesses welcomed GraphQL in 2015. Presently, organizations use REST and GraphQL as per API requirements, while efforts are being taken simultaneously to come up with even more efficient API architectures.

RPC is more like an age-old client-server model from the 1960s and is still a commonly used architecture, although it’s considerably older and has undergone several changes over the years.

The paragraphs below elaborate on some of these architectures in detail.

Types of API Architectures

#1 REST (Representational State Transfer)

One of the most popular API architectures there is, REST relies on an efficient client-server model separating front-end and back-end API. As the name suggests, it means ‘stateless’, i.e., no information is stored between requests. REST APIs, also called RESTful APIs, have the ability to operate via intermediate systems such as load balancers, but they can also directly communicate with a server.

REST API architecture requires that no client context be stored on the server in between requests. Clients can cache responses with REST, however, a REST API response must state if it can be cached or not. Developers use standard HTTP protocols such as PUT, GET, POST, and DELETE, to query resources represented by URIs.

#2 RPC (Remote Procedural Call)

There are 2 types to be considered here – the XML-RPC and the JSON-RPC. The former uses XML for the call encoding process, while the latter uses JSON. These protocols are designed to call methods and are more about actual actions rather than resources. RPCs demand that developers execute specific blocks of code on another system.

An important pointer to remember about RPC is that it is protocol-agnostic, that is to say, it can be executed in tandem with other protocols as well. Unfortunately, the increase in the usage of non-standard procedure names in all existing RPC APIs leads to overburdening developers.

Although a well-used model, RPC APIs are limited as far as security and capabilities are concerned, which is why their usage is not as much as REST or SOAP. They are mostly used for basic process requests in internal systems.

#3 SOAP (Simple Object Access Protocol)

SOAP has been used to build APIs for a very long time, and it usually does so with XML. This architecture lends support to an array of communication protocols such as TCP, HTTP, and SMTP. This protocol is independent and enables developers to write APIs in different ways, with added features and functionality. The SOAP specification includes an extensibility model, message construct, processing model, and protocols binding rules.

The SOAP approach helps define the construction of SOAP messages and layout the way a SOAP message is processed. It is a clearly defined standard, very structured, and tightly controlled. Since it clearly defines what must be included in messages and how they should be sent, SOAP APIs are more secure. That is why they are more often than not, implemented for internal data transfers with high security.

#4 GraphQL API Style

One of the more recent finds in the API architecture, GraphQL is gaining more and more precedence as opposed to the other protocols. GraphQL helps clients describe their data requirements in a JSON format. Not to mention, it is designed in such a way that it can work with any kind of database.

In essence, the goal of GraphQL is to provide control over data to the API consumer. Not only does this enable them to describe their data requirements perfectly, it also optimizes the overall experience, resolving queries from the customer standpoint. GraphQL is thus, more of an API consumer-centric approach.

GraphQL offers clients writing and reading access to the data; clients can send data to the server and request data as well. Furthermore, GraphQL offers a subscription mechanism for opposite communication, i.e., servers can notify clients too.

#5 gRPC

Google developed gRPC as a data exchange technology and made it available as an open-source later on. Similar to GraphQL, gRPC can be executed in numerous languages and platforms. It doesn’t use text-based data formats though; it deploys the Protocol Buffers binary format, which mandates that in a gRPC setting, both the client and server have access to the same schema definition.

Yet another benefit that this API architecture boasts of is that it supports asynchronous, bidirectional data exchange, given that it is based on the HTTP/2 protocol. For the unversed, under HTTP/2, when a client starts a connection to a target server, the connection stays open until either party closes it. That is to say, gRPC enables requests and responses to moving through the connection as well as the data streams.

gRPC undoubtedly is fast and efficient and one of the best API architectures out there. Experts vouch that it is likely to emerge as the standard for data exchange on the backend. Besides, the bidirectional streaming capabilities offered by HTTP/2 enable the gRPC protocol to be used in situations where the other architectures cannot be deployed.

API Architecture: A Glimpse into the Future

From SOAP to REST and RPC to GraphQL, API architectures have come a long way. With improved standardization in tooling, API development has become much simpler; however, the expectations from API architectures have increased as well. APIs are now moving ahead of the client-server synchronous communication mechanism and are increasingly adopting newer communication patterns. Event-driven API protocols are the latest in the API architecture ecosystem. With their help, clients need not comb servers for changes; even servers send asynchronous events to the client post any change the client may want.

Using service mesh architecture is also one of the latest trends in this arena. This format enables API developers to implement internal structures between the underlying microservices environment hosting the APIs. Thereby, API developers can deploy common functionality that is being hosted on another API. This kind of architecture enables better code reuse of the entire API framework.