/ Integration Zone Over a million developers have joined DZone.

Log In / Sign Up  

REFCARDZ GUIDES ZONES JOBS | Agile AI Big Data Cloud Database DevOps Integration IoT Java Microservices Open Source Performance Security

API-Led Connectivity
This article explores the structure and benefits of three-layer APIs for businesses taking
part in a digital transformation.

by Anupam Gogoi · Jun. 30, 17 · Integration Zone · Opinion

 Like (10)  Comment (4)  Save  Tweet  9,554 Views

Join the DZone community and get the full member experience. JOIN FOR FREE

SnapLogic is the leading self-service enterprise-grade integration platform. Download the 2018
GartnerMagic Quadrant for Enterprise iPaaS or play around on the platform, risk free, for 30 days.

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.

Download A Buyer's Guide to Application and Data Integration, your one-stop-shop for research, checklists,
and explanations for an application and data integration solution.

Like This Article? Read More From DZone

Dynamic CloudHub Deployment From API Auto-Discovery in Mule
Mule Application

Mule 3.7 with Kyro Offers 77% Free DZone Refcard

Performance Boost Foundations of RESTful Architecture

Topics: MULE , API , INTEGRATION

 Like (10)  Comment (4)  Save  Tweet  9,554 Views

Opinions expressed by DZone contributors are their own.

Integration Partner
Resources
The Future of Enterprise Integration [eBook]  Buyer's Guide to Application and Data Integration 
Cloud Elements SnapLogic

The Definitive Guide to API Integrations: Explore  The State of API Integration 2018 [Report] 
API Integrations Below the Surface [eBook] Cloud Elements
Cloud Elements
White paper: Will the Data Lake Drown the Data 
Building a Modern Enterprise Data Architecture  Warehouse?
SnapLogic SnapLogic