MuleSoft API Led Connectivity Architectural and Design Patterns

In this blog, we will discuss what varieties of API Led Connectivity architecture can be implemented. API Led Connectivity talks about three layers like Experience API, Process API and System API. Each layer has its own roles, responsibility and functionality. 

API Led Connectivity is an architectural style that connects data to application through reusable and purposeful API. API Led Connectivity comprises three layers mentioned but every time it is not necessary we require all three layers.

System API

System API allows you to fetch the raw data from the system of records like JDBC, SAP, Salesforce, AS400 etc. Data fetch from backend systems can be exposed to upstream API in a secure and reliable way.

• System API responsible for connecting backend systems and fetching required raw data.
• Transforming the data fetch from backend systems.
• Cleaning the raw data from backend systems.
• Exposing the data to the upstream API (Process or Experience API) in a secure and reliable way.
• Error Handling. Mapping the errors from backend systems.

Below questions needs to be addressed for designing right System APIs

• What will be the core functionality of System API?
• Do we require System API? 
• How many systems are involved? Do we need to create a System API for each backend system?
• What kind of security measures need to be taken care of for System APIs?
• Do we need wrapper around existing System API that is written in non MuleSoft?

Below list of things needs to be taken care while designing the System API

• System API generally not exposed publicly and it should be deployed within a private network or private port (e.g. On CloudHub, System API can be deployed on a private port within Anypoint Virtual Private Cloud).
• Always provide an internal URL to upstream API to communicate with System APIs.
• There must be one System API for one backend System. In case, if you follow Domain Driven Design there can be multiple system API for one system (e.g. You have a monolithic web service which has operations related to multiple domains, in such a case you can group operations related to domains and create multiple system API as per number of domains).
• There might be some backend systems that are not ready to pick up heavy traffic. In such cases, guard System API with Spike Control or Rate Limiting policies.

Process API

Process API is responsible for orchestrating multiple downstream API (i.e. Collecting the data from multiple downstream API). The core functionality of Process API is to implement business logic, data aggregation, routing etc.

• Exposing the data to the upstream API (Experience) in a secure and reliable way.
• Responsible for handling business logic, routing, data aggregation, routing etc.
• Error Handling. Mapping the errors from System APIs.
• Responsible for orchestration of call to System API (i.e. use of scatter gather components, choice router etc.)
• Line of Business is responsible for Process API. It is also known as layer of innovation and agility.

Below questions needs to be addressed for designing right Process APIs

• What will be the core functionality of the Process API?
• Do we require Process API?
• Does Business Logic already exist in backend service (e.g. Stored Procedure on Database having Business Logic)? Do we need to implement Business Logic in the Process Layer? (It is always good best practices to have most of the complex business logic in the backend system if they are capable. In case if backend systems are not able to handle business logic, MuleSoft provides all required components to implement any kind of business logic). 
• Who will be consumers of the Process API? (e.g. Most of the time Process API will be consumed by multiple User Experience API to promote reusability).
• What security measures need to be taken care of a Process API?

Below list of things needs to be taken care while designing the Process API

• Process API generally is not exposed publicly and it should be deployed within a private network or private port (e.g. On CloudHub, Process API can be deployed on a private port within Anypoint Virtual Private Cloud). In case, if you want to expose Process API to consumers, you can create API Proxy on top of Process API and ask consumers to connect through API Proxy. In this way, we can stop exposing Process API implementation directly.
• Always provide an internal URL to upstream internal API to communicate with Process APIs.
• Process API must be secured by applying security policies like Client Id Enforcement Policies.

Experience API

Experience API is the user facing API and it can be reused by different channels like mobile applications, web applications or any other channels.

Generally, Experience APIs are channel specific (for example, mobile application can consume mobile API, web application can consume web API etc.)

• Error Handling. Mapping the errors from Process or System APIs. 
• Consumes Process or System APIs.
• Perform data transformation according to need to consumers.
• Expose channel specific API.

Below questions needs to be addressed for designing right Experience APIs

• What will be the core functionality of the Experience API?
• Does Experience API have multiple consumers?
• Do we require Experience API?
• What security measures need to be taken care of at Experience API?
• How to secure APIs from DoS or DDoS attacks?
• Do different consumers have different security requirements?

Below list of things needs to be taken care while designing the Experience API

• Experience API must be not responsible for orchestration, routing or any business logic.
• Experience API must be enabled with strong Authentication and Authorization like OAuth 2.0
• Experience API must have extra security to avoid DoS, DDoS or any API attacks.

Now, we will see different use cases where we can implement different API Led Connectivity Patterns.

Use Case 1

We have received the list of requirements from the client to implement the right API Led connectivity pattern.

• We need to connect and fetch data from various core backend systems (including some legacy systems). Unlocking the data from the backend systems.
• There is a need to collect data from multiple systems and aggregate the data and send it to clients.
• There can be multiple consumers of APIs including web applications, mobile applications and other external consumers.
• APIs must be secured at each layer.
  • Review DZone's best practices for securing API access tokens.
• Client is looking to expose more APIs on the top of core systems. Solution must be futuristic and promote reusability.

Solution

As per requirements, we will be using three layers API Led Connectivity architecture. System Layer will unlock the system of records and Process API will collect and aggregate data from multiple systems via System API and send responses back to Experience API.

Experience API will expose the API to Mobile applications and Web Applications. In 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

We have received the list of requirements from the client to implement the right API Led connectivity pattern.

• Clients have APIs that already exist that connect to systems but written in non MuleSoft.
• There is a need to collect data from multiple systems and aggregate the data and send it to clients.
• There can be multiple consumers of APIs including web applications, mobile applications and other external consumers.
• APIs must be secured at each layer.
• Client is looking to expose more APIs on the top of core systems. Solution must be futuristic and promote reusability.
• Backend systems are legacy and complex.

Solution 1

Solution is similar to Use Case 1. Only difference is that the Process API will consume the Non MuleSoft System API (i.e. Unlocking the System of records).

Solution 2

In this solution, we will create a MuleSoft System API wrapper on the top of the Non MuleSoft API. As Non MuleSoft API is legacy and not according best practices and standardized. With MuleSoft System API, we can apply various security policies and enable analytics. 

There can be other ways where we can directly create MuleSoft System API on the top of backend systems but those are very legacy and complex. We may require additional efforts to do that like design, full development, testing etc. Related tutorial: Deploying Mulesoft on Azure DevOps.

Use Case 3

We have received the list of requirements from the client to implement the right API Led connectivity pattern.

• There can be multiple consumers of APIs including web applications, mobile applications and other external consumers.
• APIs must be secured at each layer.
• Client is looking to expose more APIs on the top of core systems. Solution must be futuristic and promote reusability.
• Backend systems are legacy and complex.
• All business logic is written in the backend system and that is very complex and took years to build.
• There is no requirement of orchestration of calls.

Solution

In this solution, we don’t have to implement any business logic or need to perform orchestration of calls and all business logic written in backend systems.. So there is no need for the Process API. So Experience API can directly System API.

Use Case 4

We have received the list of requirements from the client to implement the right API Led connectivity pattern.

• There will be only one channel consuming the API.
• APIs must be secured at each layer.
• Client is looking to expose more APIs on the top of core systems. Solution must be futuristics and promote reusability.
• We need to connect and fetch data from various core backend systems (including some legacy systems). Unlocking the data from the backend systems.
• There is a need to collect data from multiple systems and aggregate the data and send it to clients.

Solution

In this solution, we will not create an experience API directly as we will have only one channel that will be consuming the API and process to obey all the requirements of consumers like API Specifications. In this case, consumers can directly consume process API or we can create Proxy API on the top of Process API to hide actual implementation. Many organizations choose between an API proxy or API gateway to handle this.

Now you know there are different flavors of API Led connectivity that can implement.