API-Led Connectivity

Today, in the age of APIs, an API is not just a technical interface on top of a database. On the contrary, your API is your new business model. In the past, APIs were just seen as tools for developers. But nowadays, their scope is not limited to internal use; API makers are exposing their APIs for external users around the globe. For example, Google Maps APIs use the Uber APIs to calculate fare and travel time to destination. 

This API-led business model is a new way of thinking how to engage with partners and customers through APIs. In other words, your product is the API, so one must take proper care to design it based on business criteria, deploying, and managing the APIs.

In this article, I am going to discuss the paradigm of API-led connectivity, which has gained a lot of popularity in this decade.

The Digital Transformation

Digital transformation is happening everywhere with the involvement of mobile and cloud technologies. APIs, once seen as developers' tools, are now being exposed to the market. For example, Amazon sells its product through third parties with the Product Advertising API. 

However, digital transformation is not an easy task. It involves the ability of organizations to bring in multiple technologies to create distinctive and disruptive services to the market. To happen this they must be able to retrieve data/information from disparate sources and provide them to multiple consumers (customers, suppliers, and employees) in various formats. 

Problems With Traditional Connectivity Approaches

The traditional approaches used for integration applications do not work for digital transformation. These approaches were designed where fewer endpoints were necessary to meet the business needs as well as the speed of delivery was not considered too much. Here are the problems faced with the traditional integration approaches:

P2P Approach

In the P2P approach, one business operation is connected to another operation by direct connection. In an organization where a lot of applications need to be integrated, it becomes a mess with the P2P approach. Here are the main drawbacks of this approach:

• Hard to change.

• Maintainability.

• High operation risk.

• Time to market.

E2E

This approach focusses on centralizing information as much as possible. In this approach, an integration platform is used (ESB), which serves as the base for collecting all the information and serving them to the final receiver. It centralizes and reuses components like logging, error handling, transactions, etc. This approach is much more efficient than the P2P approach. However, to meet the digital transformation of today's age, it is still not efficient enough, because "time to market" is still longer with this approach. 

So, to overcome these problems, the new approach of API-led connectivity is born.

API-Led Connectivity

This approach is based on Pace layers. The main purpose of API-led connectivity is to enable the integration flows to be reused by many parties and to be reused inside the integration platform. With the reusability of the already available logic (implemented in flows), the developers can evolve their logic in faster and safer ways, leading to a short time to market. APIs are created in layers and the best plus point as compared to E2E approach is that more components (flows) can be reused which makes easier to implement new systems and services.

Research shows that the API-led connectivity approach makes the development process 3 times faster, as one does not need to reinvent the wheel, decreasing the time to market. As the reusable APIs are already tested, the use of them makes the new implementations bug-free. The reduced development time reduces the integration costs by around 70% (as per the statistics).

In this approach, the APIs are based on three distinct layers: System, Process, and Experience. With API-Led architecture, the IT infrastructure of an organization should look more or less as shown in the diagram below.

System Layer

This is the foundational layer of the three-layer architecture. These APIs can be defined for various domains of an organization, for example, ERP, key customer and billing systems, proprietary databases, etc. System APIs provide a means of accessing these underlying systems of records and exposing the data in canonical formats. A System API defines the contract RAML/WSDL to describe how to interact with the domain. For example, a System API for a customer domain can contain resources with methods like GET, POST, PUT, and DELETE, and the related schemas (XSD, JSON) and responses (200, 400, 500, etc).

Basically, one can see that System APIs generally expose the sensitive information of an organization. They should not be exposed for public use.

Process Layer

Process layer APIs are responsible for shaping the data by orchestrating and choreographing various data by calling multiple System APIs. The orchestration involves the aggregating, splitting, and routing of data. The main purpose of Process APIs is to strictly encapsulate the business process independent of the source systems (System APIs) from which the data originates. 

For example, in a purchase order process, it needs to interact with various domains of the organization. The Process API (purchase order/order fulfillment) interacts with the already available System APIs to implement the logic.

The Process APIs should be held privately inside the organization as per recommendation and should not be exposed for public use.

Experience Layer

At this point, we have all the sensitive information of an organization exposed privately by System APIs, and the Process APIs have already exposed the business process logic. The business process data is consumed across a broad range of clients/channels with different formats. For example, our Order Purchase API (Process Layer) has exposed data in the JSON format, but we have a client application that accepts only XML format, or vice versa. This simple transformation logic is implemented in the Experience Layer and the implementations are exposed as Experience APIs.

In other words, Experience APIs are the means by which data can be reconfigured easily to meet the needs of multiple audiences. Also, we can remove the unnecessary methods and expose only the necessary methods in Experience APIs in a simple way.

The Experience APIs are the ones which should be exposed publicly for consumption. In short, they are the final products of an organization in the API-led connectivity approach. Various policies can be applied to the APIs as well, as they can be monetized to earn revenue for the organization.

Main Advantages of Three Layer APIs

The main benefits of the three layer can be summarized as below.

System APIs

One can modify the System API logic without affecting the other APIs (Process and Experience). For example, if a System API is using SAP and, in the future, SAP needs to be replaced with Salesforce, this replacement can be done easily modifying only the System API without touching anything in Process and Experience layers. 

Process APIs

Common business logic can be shared across the organization. For example, if an organization already has the purchase order process API implemented, it can be reused whenever necessary.

Experience APIs

Experience APIs are simple. Basically, they involve only the transformation of data. So, to meet a wide range of clients that accept data in diverse formats, the Experience APIs do this rapidly, decreasing the time to market.

Role of Mulesoft in API-Led Connectivity 

The Anypoint Platform provides a very nice integration framework as well as an API management platform. Using the Anypoint Platform as a whole, one can achieve API-led connectivity in a smoother way. 

In this article, I have given a brief overview of API-led connectivity. In the next article, I will try to show how to achieve this with some examples using Anypoint Platform. 

Thanks.