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 seen as just tools for Developers. But nowadays, their scope is not limited to internal use. The companies who make APIs are now exposing them APIs to external users around the globe. For example, Google Maps' APIs use Uber's APIs to calculate fares and travel times to destinations.
The API-Led business model brings forth a new way of thinking focused on how to engage with partners and customers via APIs. In other words, your product is the API. So, one must take proper care while designing based on business criteria as well as the deployment and management of APIs.
In this article, I am going to discuss the paradigm of API-Led connectivity, which has gained a lot of popularity throughout this decade.
Nowadays, digital transformation is occurring everywhere due to the involvement of Mobile and Cloud technologies. APIs which were once seen solely as tools for developers, are now being exposed to the market. For example, Amazon utilizes the Product Advertising API to sell its product via third parties.
However, digital transformation is not an easy task. Essentially, organizations are creating revolutionary technologies to bring forth distinct and disruptive services to the market. In order to do so, organizations must be able to retrieve data/information from disparate sources and provide them to multiple consumers (customers, suppliers, and employees) in various formats.
The traditional approaches used for integration applications do not work for digital transformation. These approaches were designed at a time when fewer endpoints were necessary to meet business needs, and when the speed of delivery was not considered to be important. Here are the problems faced with traditional integration approaches:
In the P2P approach, one business operation is connected to another operation by a direct connection. In an organization where a lot of applications need to be integrated, the P2P approach can be extremely messy. Here are the three main drawbacks of this approach:
Hard to change
Maintenance
High operation risk
Time to market
This approach focuses on centralizing information as much as possible. In this approach, an integration platform (ESB) is used to act as the base for collecting all the information and serving them to the final receiver. It centralizes and re-uses components: e.g logging, error handling, transaction etc. This approach is much more efficient than the P2P approach. However, in order to meet the digital transformation of today's age, it is still not efficient enough.
So, in order to overcome these problems, the new approach of API-Led Connectivity was created.
This approach is based on Pace layers.The main purpose of API-led connectivity is to enable the integration flows to be re-used by many parties, and to be re-used inside the integration platform. With the re-usability of the already available logic implemented in flows, the developers can evolve their logic in faster and safer ways, resulting in high uptime to the market. APIs are created in layers, and the key factor that differentiates them from the E2E approach is that more components (flows) can be re-used, which allows an easier implementation of new systems and services.
Research shows that the API-led connectivity approach makes the development process 3 times faster because there is no need to constantly re-invent the wheel and decrease the uptime to market. Because the re-usable APIs are already tested, new implementations will be bug free. According to statistics, the reduced development time reduces the integration costs by around 70%.
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 like in the diagram below:
This is the foundational layer of the three-layer architecture. These APIs can be defined for various domains of an organization such as ERP, key customer and billing systems, proprietary databases, etc. System APIs provide a way to access these underlying systems of records and expose the data in canonical formats. A System API defines the contract RAML/WSDL in order to describe how to interact with the the domain. For example, a System API for a Customer domain can contain resources with methods GET,POST,PUT,DELETE, etc., and the related schemas (XSD,JSON) as well as responses (200,400,500 etc.).
So basically, we can see that System APIs often expose the sensitive information of an organization. They should not be exposed for public use.
Process layer APIs are responsible for shaping the data by orchestrating and choreographing various data through 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, a Purchase Order process requires various domains within the organization to interact. So the Process API (Purchase Order/Order Fulfillment) interacts with the already available System APIs to implement the logic.
The Process APIs shoud be held privately inside the organization and should not be exposed for public use either.
Now at this point, we have all the sensitive information of an organization that are exposed privately by System APIs, and the Process APIs have already exposed the business process logic. The business process data are consumed across a broad range of clients and channels in different formats. For example, our Order Purchase API (Process Layer) has exposed data in JSON format, but we have a client application that only accepts XML format. So, we utilize simple transformation logic 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 easily re-configured in order to meet the needs of multiple audiences. We can also utilize Experience APIs to simply remove unnecessary methods and expose only necessary methods.
Experience APIs may be publicly exposed 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 and they can also be monetized to earn revenue for the organization.
The main benefits of the three layers can be summarized below:
One can modify the System API logic without affecting the other APIs (Process and Experience). An example would be when a System API is using SAP, but SAP will need to be replaced by Salesforce in the future. This replacement can be done easily by modifying only the System API and not the Process and Experience layers.
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 re-used whenever necessary.
Experience APIs are simple. Basically, they only involve transformation of data. So, in order to satisfy diverse clients that accept data in various formats, the Experience APIs can do so rapidly and decrease uptime.
Role of Mulesoft in API-Led Connectivity
The Anypoint Platform provides a very nice Integration Framework and an API Management platform. Using the Anypoint Platform can result in achieving a smoother API-Led connectivity.
In this post, I have given a brief overview of API-Led connectivity. In my next post, I will try to show how to achieve this with some examples using Anypoint Platform.