In today's blog, we will discover the power of API-led connectivity in Part 3 of our series. Explore use cases, from unlocking data to securing APIs at each layer, and learn how MuleSoft's architecture fosters reusability, flexibility, and innovation in digital transformation.

Introduction

In the previous part of the series, we have gone deeper and have looked at the structure of an ideal system that implements API-led Connectivity. In addition, we have also witnessed how API-led Connectivity can entirely improve how IT works and delivers by promoting the reusability of APIs, the composable structure and automated processes.

API-led Connectivity is simple, efficient and it allows faster and more secure data flow in the systems. It is also known for its flexibility and ability to adapt to different situations. For this final chapter of this series, we will go over different use cases that require different API-led connectivity patterns.

Use Case 1:

The client wishes to implement a system using API-led connectivity with the following requirements:

• Data needs to be unlocked and collected from various core backend systems.
• Collected data needs to be aggregated and sent to consumers.
• There are multiple end-users / consumers of APIs including web applications, mobile applications and other external consumers.
• APIs must be secured at each layer
• The client wants to expose more APIs on top of the core systems. The solution must be futuristic and promote reusability.

Solution:

As per requirements, we will be using the three-layer API-led connectivity architecture. The system layer will be in charge of unlocking the backend systems. The process APIs will collect and aggregate data from multiple systems via System APIs and responses to the Experience layer.

Experience API will expose the API to the Web / Mobile Application. In the future, we can add more channel-specific APIs at Experience Layer and reuse process and system APIs. APIs will be secured at each layer by applying API policies and other security components.

Use case 2

The client wishes to implement a system using API-led connectivity with the following requirements:

• Clients already have APIs that connect to backend systems, but they are not developed using Mulesoft.
• Data needs to be collected from these backend systems and aggregated after to be sent to consumers.
• There can be multiple consumers of APIs including web applications, mobile applications and other external consumers.
• APIs must be secured at each layer.
• Expose more APIs on top of the core systems. The solution must be futuristic and promote reusability.
• Backend systems are legacy and complex.

Solutions

For this particular case, we can come up with two solutions that guarantee to meet the requirements to use API-led Connectivity and keep the legacy backend systems intact.

Solution 1:

This solution is similar to that for Use Case 1. The only difference is that the process APIs will consume the Non Mulesoft System APIs.

Solution 2:

For this solution, we will create Mulesoft System APIs that wrap around the Non Mulesoft APIs. There are other ways that we can directly create Mulesoft System APIs on top of the backend systems, but as the systems are legacy and complex, we avoid tampering with them. With Mulesoft System APIs, we can apply various security policies and enable analytics. Additionally, just like in Use Case 1, each layer is secured with appropriate security policies.

Use Case 3

The client wishes to implement a system using API-led connectivity with the following requirements:

• There can be multiple consumers of APIs including web applications, mobile applications and other external consumers.
• APIs must be secured at each layer.
• Expose more APIs on top of the core systems. The solution must be futuristic and promote reusability.
• Backend systems are legacy and complex.
• All business logic is written in the backend systems, and they are very complex.
• There is no requirement of aggregating data or orchestration of calls to System APIs

Solution:

For this solution, as per requirements, we don’t have to implement any business logic or need to perform orchestration of calls to System APIs as all business logic written in backend systems. Therefore, we can skip the process layer and the experience layer can call the System APIs directly.

Use Case 4

The client wishes to implement a system using API-led connectivity with the following requirements:

• There will be only channel consuming the API.
• APIs must be secured at each layer.
• Expose more APIs on top of the core systems. Solutions must be futuristics and promote reusability.
• Data needs to be collected from various backend systems and aggregated and sent to consumers.

In this solution, we will not create an experience API directly as there is only one channel consuming the APIs. In this case, consumers can directly consume the process API, or we can create Proxy API on top of it to hide actual implementation.

Conclusion:

Through this 3-part series, we hope that you understand the basic concepts that surround API-led Connectivity. It is a three-layer architecture with each layer in charge of a particular role that guarantees the fluidity of the data flow. API-led connectivity provides an approach toward a more innovative way to digital transformation through the use of reusable and composable APIs. It is a big leap away from the traditional point-to-point integration that helps developers avoid the clumsy and messy “spaghetti” code. By applying API-led connectivity, IT can deliver much faster by reusing the already developed building blocks and having more time on their hand for innovation rather than keep working on one project repeatedly.