An API platform brings in a new dimension to the ubiquitous usage of APIs. When you look at APIs in silos, the focus is on a single API to get a job done as per its specification.
API Platform is a framework that allows you to build web applications and services on top of your existing APIs. It enables you to create your own RESTful APIs and manage the API lifecycle, including versioning, documentation, testing and packaging. It also allows you to create a comprehensive set of tools for managing the API life cycle.
But as the saying goes, “Unity is strength,” why can’t we apply this benevolent idea to the world of APIs? This is exactly what you can achieve with an API platform. It combines the power of multiple APIs to create a whole new experience for API consumers.
In this blog post, we present a few possibilities for building an API platform. However, the term “API platform” is used equivocally in different contexts. Therefore, it requires clarification. We begin with an objective definition of the API platform, followed by the key architectural patterns for building custom API platforms, along with examples. Finally, we cover the nuances of deploying and managing an API platform. Let’s dive straight in and understand what an API platform is.
Table of Contents
What is an API Platform?
An API platform is a way of blending the features of multiple APIs. It brings together individual APIs to form a unified, consolidated interface. In this way, an API platform offers a bouquet of enhanced services around a set of related and complementary APIs. Thereby it increases the potential of broader adoption and monetization.
How do you make an API platform?
An API platform has a laser-sharp focus on the use case. Therefore, thinking about an API platform requires combining multiple APIs’ capabilities to serve a niche.
A simple example is a personal finance application that generates customized tax reports for different countries in local languages. A combination of three APIs for tax calculation, currency conversion, and language translation achieves this goal. By wrapping them within a backend API platform, any fintech SaaS application that requires such custom tax reports can use them via a single API interface provided by the API platform. Adding more specialized APIs to the platform builds newer capabilities for the application.
Benefits of API Platform
Thinking in terms of API platforms is beneficial for all stakeholders:
- For API Producers: API platforms open up design win opportunities for API producers. It brings in the ecosystem play where APIs are monetized as part of an API platform serving a domain-specific application.
- For API Managers: Managing multiple APIs in a consolidated way is much easier for the API Ops team than governing the APIs individually.
- For API Consumers: API platforms offer a better end-user experience for API consumers. Since most APi consumers are developers, it translates to a better and simpler developer experience.
From a company’s perspective, API platforms should be first-class citizens in their API strategy roadmap. This enables them to build standardized service backends. By mandating specific APIs to be used within an API platform, companies have better control of the selection and choice of APIs. Ultimately this approach delivers consistent outcomes for all departments using the API platform.
Rakuten RapidAPI Enterprise Hub offers a full-fledged API management suite for managing an internal API marketplace within your organization. With the help of this solution, you can seamlessly define and implement successful API strategies. Through single window access to all APIs, the Enterprise Hub makes it easy to discover, test, and consume APIs with ease. It also leverages the Rakuten RapidAPI marketplace, the world’s largest API marketplace with over ten thousand APIs.
API Platform Architecture
Building API Platforms is more than just grouping together a set of APIs. Like any software platform, the innards of an API platform also have to adhere to specific guidelines.
Every API platform has two partitions consisting of the outer APIs and the inner APIs at its core. The outer APIs are the ones that are exposed to the outside world. These APIs form the interface specification for the API platform. The inner APIs are the actual APIs that perform a specific task in line with the API platform’s overall objective.
The outer APIs and the inner APIs are tied together through an orchestration layer, typically an API management software like Rakuten RapidAPI Enterprise Hub.
There are some common architectural patterns for arranging APIs within an API platform.
API Library Pattern
This pattern is the simplest form of an API platform. It is formed by bunching together a few APIs that perform related functions. The outer API acts as a higher-level abstraction and isolation layer to route specific client requests and responses to and from the inner APIs.
API Stack Pattern
An API stack pattern offers a set of APIs stacked together to provide a full-service capability.
This pattern is similar to a typical communication protocol stack. Here the outer API invokes an inner API. The inner API’s response feeds another inner API’s request. This sequence follows until the final API response is returned to the outer API and sent back to the client.
API Flow Pattern
An API flow pattern is formed by bunching together APIs horizontally rather than stacking them vertically.
In this pattern, the APIs form a chain that depicts a process flow. Typically, this process flow establishes a link between two applications. After being processed through the API platform, one application’s output feeds into another application’s input.
This pattern may not follow a strict ordering of one API response feeding into another API, unlike the API stack pattern.
API Platform Examples
Based on the architectural patterns, let’s explore some possibilities for building API platforms for the real world.
Notification Management
Sending a notification is one of the most common requirements in an enterprise-wide IT deployment. The real hassle lies in managing the notification settings and the complex integration across many notification mediums, such as SMS, emails, app notifications, and external webhooks.
When dealing with many such integrations, third-party notification service providers make the job easy for developers to integrate notifications in their applications.
Let’s take the example of a bank. This bank offers several online banking services to its customers, as part of which the customer can opt for receiving notifications via SMS, email, or push notification. They need a mechanism to capture the customer’s notification preferences. Along with that, they also need a way of triggering and dispatching notifications whenever certain events occur.
If they decide to leverage API for achieving this entire goal of managing and triggering the notifications, then they have three options:
Option 1: Let developers developing the individual online service choose third-party APIs for sending notifications and building custom integrations for managing them.
Option 2: Approve a few third-party APIs to be used company-wide for sending notifications. Let the developers build their own notification management APIs that internally call one among the approved APIs.
Option 3: Build a set of common APIs for handling company-wide notification sending requirements.
If they select Option 1 as the way forward, it is a clear sign of a lack of maturity in API strategy. Leaving everything to the developers leads to inconsistencies in the API interface and unpredictable performance of notification service.
Option 2 is good because it standardizes the notification APIs for each sending medium. However, if different development teams build their own notification management around these APIs, this leads to duplication of effort. The problem of inconsistent API interfaces still exists in this case.
By choosing Option 3 over others, the company taps into the virtues of an API platform. A separate API platform development team is commissioned to design and build a custom notification service. This service is used across all development teams. This approach creates a unified API interface for notification management operations and standardizes the notification dispatch mechanism.
This API platform follows the API flow pattern. It chains multiple APIs as follows:
- Notification Management API: This API manages the configurations for adding, updating, and deleting the notification settings and rules.
- Notification Trigger API: This API checks for the rules to decide whether the notification has to be sent or not.
- Notification Dispatch API(s): This is a bunch of approved third-party APIs triggered from Notification Trigger API to send the notification message on a specific medium.
In this way, API platforms provide an equivalent of the software facade pattern that hides the complexities of notification management and dispatch from the API consumer.
Cloud Layered Service Backend
There is often a need for arranging a set of complementing APIs to form a standalone backend service. This scenario is a perfect way of stacking up APIs together to serve a client request in unison.
Take the case of the weather forecast. If a company wants to develop a worldwide weather forecast API, it requires some customizations for the weather data display. Specifically, this applies to two things. One is the scale of measurement, metric vs. imperial. The second is the language.
So if the weather service API has to cater to an audience from all over the world, it must return the weather data in a chosen scale and language specific to a county.
In this case, a custom API platform for weather service is realized by stacking three APIs. The weather API output is fed to the measurement scale API, which feeds into the language-translation API.
MXDP Library Suite
MXDP stands for Multi Experience Development Platform. Multi experience refers to the union of multiple modes of interaction choices that the users have concerning their digital experiences. Gartner has published a report on MXDP platforms that lists the development tools, libraries, and platforms supporting multiple user experiences around touch, voice, and gesture.
By extending the concept of MXDP to APIs, there are new possibilities for building API platforms. This is envisaged in a library of related APIs for multi-experience development around a specific application.
Extending our previous example of the weather service API platform, building a library of weather APIs tailored to multiple experiences is also possible. For instance, while using a weather app to find the city’s current weather condition, the users may scroll through the list of cities. Alternatively, they may key in the city name or speak the city’s name. These are three separate touchpoints to interact with the app.
Accordingly, an MXDP API platform for weather can be realized to offer three APIs for:
- Fetching the thumbnail images of the weather condition for cities,
- Auto Completing the city names based on partially typed text
- Matching the speech pronunciation of the city name with a city.
This platform follows the API library pattern.
Now the API consumers have more choices to embed multi-experience features within their weather apps by leveraging this API platform.
Rakuten RapidAPI Enterprise Hub supports RapidQL. RapidQL is an open-source query language that makes it easy to build custom API platforms by aggregating multiple requests into one. You can also use RapidQL to simultaneously make requests to APIs and databases, defining only the fields you need to be returned from each.
Deployment Considerations
Tying multiple APIs together to create an API platform may seem easy at first. But there is a challenge. As a good design practice, all APIs are designed to work independently. They perform a well-defined task that meets a specific objective. Therefore, deploying interlinked APIs within an API platform’s bounds has some additional considerations.
Challenges in Deployment
1. Low-Level Design: The low-level design of API platforms constitutes a few intermediary tasks, such as transforming the API requests/responses or coupling the output of one API to the input of another API. Since all APIs are self-contained entities, this coupling cannot be achieved directly. You need an additional set of APIs acting as a glue layer within the API platform’s internal architecture.
2. Governance: An API platform consists of more than one APIs. As a result, there is a need for combined governance of APIs such that all APIs within the platform have uniform governance policies assigned.
3. Security: The challenges of governing the APIs within a platform also apply to security. Most of the API security concerns revolve around API keys and user access permissions and policies. This also extends to API traffic management, wherein all the constituent APIs of an API platform need a consistent configuration for traffic policing.
Best Practices
To circumvent the challenges, here are some good practices that will help you take a leap and expedite the launch of API platforms with long-term gains.
1. Choosing an API Management platform that supports API platforms: API management platforms play a crucial role in fostering the ecosystem around APIs and API platforms. Additionally, they provide enhanced features for better management API platforms, such as:
a. API packaging: Packaging multiple APIs into a suite of services or products for better governance and tracking and easier discovery for API consumers.
b. Custom extensions: Configurable and programmable extensions to customize API requests or responses.
c. Access management: Providing robust workflows for managing API subscriptions and consumption for the API platform as a whole, over and above individual APIs.
2. Bringing in a service mesh component: A service mesh enables a system’s internal components to share data seamlessly. In APIs, service mesh enables the so-called east-west interface between the API backend to share data and serve internal requests as part of other APIs invocation. Service mesh makes it easy to build the internal glue layers across API platforms to reuse APIs better.
3. Leveraging the microservice architecture pattern: A microservice-based application partitions an application into independent service components. In API platforms, the outer APIs, inner APIs, and glue APIs have different deployment and scaling requirements. Therefore it is advisable to manage them as separate components by leveraging microservices from the beginning.
Evolving Trends in API Platforms
There are a few areas where evolution in APIs is helping in the advancement of the API platforms. GraphQL is one of them. GraphQL dramatically simplifies the interface specification for a multi-faceted API platform by compacting the URL endpoint and defining a schema-based specification.
However, advancements in API platforms are more focused on building a back-end component serving an application, either in part or as a whole. Therefore, most of the technologies used for creating and scaling application back-ends fall within the realm of infrastructure and orchestration layers. For example, containerized and serverless workloads can scale the infrastructure, while tools like Kubernetes help manage such workloads dynamically.
With the advent of Async APIs, the deployment requirements for the API platform will face further challenges. In the traditional REST architecture, the client maintains the application’s state and queries the server based on that state-related information. For Async APIs, this dependency is going to invert with servers maintaining state information.
Considering this change, an API platform supporting Async APIs will have to support databases and other components to handle application-specific state information soon.
Leave a Reply