APIs represent a significant part of any web-enabled software. With the rise of the “as-a-service” model of software delivery, APIs also offer a consistent pattern for building modular and scalable systems. Therefore, we are witnessing a radical shift in the evolution of software architecture. Instead of embedding a bunch of APIs within, entire software systems are being conceptualized as APIs.
More...
This architectural shift brings in new opportunities and challenges for software developers. Through this blog post, we intend to build a technical awareness of API architecture. We cover the innards and also delve further into the guidelines for building robust APIs.
This article was originally published at RapidAPI
What is API Architecture?
API architecture refers to a software building block that implements an API. For example, if we look at the TCP/IP protocol, many layers form the building block of this protocol stack. They are all arranged in a specific order. Individually, they perform a single, well-defined responsibility. But, collectively, they achieve the transmission of data between two devices through the Internet.
It is possible to envisage an API architecture in the same way. However, before getting to that, defining the core responsibilities of an API is crucial.
As evident from its acronym, an API provides a mechanism for invoking a task on another system. There are four primary responsibilities of an API.
1. Interfacing: The interface defines the specifications for accessing the API. In the context of a web API, this interface defines the protocol specifications for accessing the API over the Internet.
2. Interpretation: The data sent as part of an API request and response is subjected to interpretation. This is done to take additional actions or translate between human and machine, user and platform interpretable data formats.
3. Computing: As part of its core function, an API executes a business logic. Therefore it requires a computing environment.
4. Data Processing: All applications rely on some data store that necessitates transfer, dump, or fetching of loads of data. An API relies on these operations too.
Building Blocks of an API Architecture
To better understand the API architecture, let us split the API responsibilities into individual entities accountable for them. In this way, we stitch the building blocks that define the generic API architecture.
API Interface Block
The Interface block is responsible for defining the specifications for the API. This is important for the external world to access the API. In most cases, these specifications are governed by the application layer protocol that hosts the API.
HTTP is the most ubiquitous protocol that carries the API payload. Therefore the API interface is defined in terms of the API endpoint URL, the port number, and the HTTP method. The API interface also defines additional HTTP headers.
One of the other popular protocols is MQTT. It is based on the publish-subscribe pattern and makes it easy to build async APIs. In this case, the API endpoints are identified by a topic name instead of the URL.
API Controller Block
Beyond the interface, an API needs to control the ingress and egress traffic. This is where the API request and responses are interpreted, and additional control mechanisms are applied via the Controller block.
Some of the most apparent control mechanisms include rate limiting, throttling, blacklisting. This is to ensure that the client applications do not misuse the API. It also guards against abuse of the API.
Even more important is the handling of unauthorized access to API. Therefore this building block is also responsible for authentication and authorization. Additionally, it has the ability to peek inside the HTTP headers and data payloads to perform additional checks and transformations.
API Runtime Block
The Runtime block takes care of the computing responsibility of the API.
Behind the scenes, every API is a piece of software that performs a well-defined business logic serving the needs of the API’s client.
Depending upon a chosen programming language and its toolchain, a runtime environment gets spawned. Then, the business logic execution happens inside this runtime environment, supported by additional configuration data and environment variables.
API Data Bridge Block
Usually, the data storage engines, like the databases or any form of data store, are universally shared between the individual APIs that form the API service. This approach ensures that there is a single source of truth across all APIs. The APIs must have a bridge between their runtime block and the data engine to facilitate seamless access to data.
The Data Bridge block is responsible for orchestrating this data access. The actual implementation of this block is platform-specific and depends on database drives and programming libraries. These are managed from within the Runtime block.
Additional Components of API Architecture
What we covered until now is the architecture of a single API. However, APIs do not live in isolation. Instead, an individual API is a part of the API service, with many API endpoints, each having its path and request, response semantics. Additionally, a software built around APIs might leverage multiple such API services.
Therefore, big picture thinking is required for the overall architecture of API service.
API Management
API management refers to the overarching administrative processes for managing multiple APIs. It involves several interventions to manage the entire lifecycle of APIs.
API management is an integral part of any API-led strategy within an enterprise. It is facilitated via an API management platform that oversees all the administration, deployment, and monitoring of APIs. It also orchestrates the coordination between the API developers, consumers, and the operations teams.
For a closer look on the subject of API management and the various vendors, check our our detailed analysis of the best API management platforms.
Service Mesh
A service mesh is like a common logic fabric that connects multiple APIs.
In the development of any software, many commonalities emerge out of the overall business logic. These are bunched into a set of standard modules reusable across multiple components.
This principle applies to API-led software development as well. A suite of API services will have many APIs that criss-cross each other due to the interdependence of common business logic. Therefore, service mesh acts like an intermediary sub-system that allows APIs to talk to each other in a well-coordinated manner.
Choosing and deploying a service mesh is essential to scale API services. Above all, it provides a robust framework to deploy service-wide API architecture.
Security
The basic authentication and authorization handled by the API Controller block takes care of access security. But it does not guard against some of the more significant security threats on the Internet.
Malicious personalities frequently adopt DDoS (Distributed Denial of Service), man-in-the-middle, and other organized hacking attempts to disrupt the API services and steal information. Therefore, the API architecture must add additional security layers to handle such macro-level security threats.
API Architecture Best Practices For Deployment
The architecture of any system defines the internal sub-system, component level arrangement to ensure smooth functioning. But when the rubber meets the road, that is the actual test.
The same applies to APIs as well. Despite the best architectural choices, the API service as a whole must perform well in a real-world deployment. Here are a few guidelines to consider.
API Modelling
API modeling defines how the APIs mimic the real-world service that they represent. REST is the most ubiquitous way of modeling APIs. It is a prescriptive framework for designing API. It lays out guidelines to balance the API semantics and functionality such that the APIs model the real-world application.
Most importantly, REST allows the individual APIs to have distinct separation of concerns, suitable for modular architecture.
Hosting Considerations
APIs are hosted under various server configurations. Many options exist between the server and serverless setup, each having its pros and cons.
However, it is imperative to choose a hosting configuration that augurs the business goals for the API service. While the API architecture is agnostic of this decision, the overall cost vs. performance tradeoff is undoubtedly a matter of consideration.
Scalability
The projected traffic for any API service is always a challenge to foresee. Whether it is about handling growth or seasonal fluctuations, the API requests and responses have to be channeled so that the API service is elastic enough to handle extreme limits in traffic variations.
These circumstances call for having an additional deployment architecture that can handle scale. It is an outer layer of computing fabric that encapsulates the API architecture and helps it scale horizontally.
Conclusion
The API architecture presented here is a baseline reference. In addition, there are vendor-specific implementations that combine the standard architectural building blocks or add new ones to manage and govern APIs.
To get a better view of API architecture, it is worthwhile to study API gateways. These are available both as PaaS and IaaS offerings from various cloud service providers and software vendors.
Amazon API gateway is a popular PaaS offering that allows developers to configure and build APIs for hosting applications on the AWS cloud. For fine-grained control and customized deployment, NGINX is a popular choice. It is battle-tested for handling heavy loads and offers a robust architecture for deploying scalable API services.
