Every day we hear that we must evolve to the world of APIs, that we must leave behind the classic SOA, we hear advantages of this model and how developers can self-provide and reuse existing APIs. We also hear about how we can expose our business to partners through API, etc. But what is really an API? How to design them and what do manufacturers offer to handle and manage them? We make an introduction to the world of application programming interfaces and how one of the most important API Management manufacturers solves this challenge.


What is an API?
An API (application programming interface) is an interface that facilitates access to services or databases, so that they enable the interconnection of modules and applications, facilitating access to their backend and thus allowing the reuse of services.

Through programming, it allows us to open data and functionalities to other developers, companies or even departments of the same company. In this way it becomes the new way in which organizations will exchange data, services and resources with both partners and the general public.


What problems do they solve and what aspects should we consider?
Connectivity: its use allows the connection of software components remotely.
Technological independence: the use of a certain API does not have to be associated with the use of a certain technology (.NET, Java, …).
Functional: APIs generated and published have to solve a need and offer full functionality.
Security: the publication of certain functionalities to third parties, implies this challenge to solve.
Scalability: enabling services for use by third-party systems can lead to a high growth in the number of calls to the system. The service exposed via API has to be implemented using easily scalable solutions.
Agility to change: increasing the potential number of API users also increases the number of potential needs / improvements on them. The architecture created has to facilitate the evolution of APIs and functionalities, allowing a quick response that meets the expectations of the high number of users and allows responding in advance regarding the competition.
Documentation: the API creation process is associated with a documentation and publication process. The objective is to have a platform, API portal, in which the potential users of them can have all the necessary details for their use.
Access levels: the use of API implies a level of service provided by them. In order to guarantee this level of service, it is essential to control the level of access to these APIs. This control can be used when monetizing the service, allowing the creation of different levels of access and therefore different costs.
How do we manage to control all these aspects?
We can define API Management as the process of publishing, promoting and monitoring APIs in a secure and scalable environment. In addition, the term includes all those resources focused on creation, documentation and socialization. This concept is the key to the success of an API platform as it will give us a solution to the problems we are going to encounter.

What is Mulesoft’s approach to the world of APIs?
Mulesoft has one of the leading products in the market, Anypoint Platform, which not only aims to be an integration technology platform, but also promotes an API management methodology through it that facilitates the use of its APIs and their reuse .

The approach that the tool offers, “API-led connectivity”, is a way to connect data and applications through reusable and functionally complete APIs. These APIs are developed to play a specific role by converting data into processes and offering different integration methods.

The solution proposed by Mulesoft includes in a single product the three pillars necessary for the API Management:

API Gateway
API Manager
API Portal
In addition, incorporating its own Runtime as well as numerous connectors to the most important systems in the market (Salesforce, SAP, Siebel, etc.) also includes the capabilities of an ESB. In addition, it covers the entire software life cycle and includes a DevOps oriented product approach.


The “API Led Connectivity” approach is based on generating reusable assets and on a three-layer architecture, not only with its own components but using hybrid architectures.

1. Experience API

This layer is what consumer systems use. It is oriented to the consumer in a way that facilitates and optimizes the integration according to their needs. In addition, they develop thinking of reuse by similar consumers. Additionally, the scalable design of this layer allows new consumers to be incorporated without impacting existing consumers and reusing the logic implemented in the lower layers.

2. Process API

APIs dedicated to implementing the logic of business processes are developed in this intermediate layer. They are reusable by all Experience APIs in the upper layer, and orchestrate the calls to the different System APIs in the lower layer. The incorporation of new business processes through new Process APIs does not impact existing components and new components can reuse existing System APIs if necessary. Communication between this Process API and the System APIs is done through REST.

3. System API

It is the layer of services that will provide connectivity with the final systems, totally oriented to the characteristics of the Backend, also called the microservices layer. They are APIs dedicated to executing operations in the supplier systems. In addition, they are reusable by all Process APIs and the need to execute new operations on existing systems (or new systems) does not impact existing operations. Each System API connects to a provider system.

In the current environment in which the input channels do not stop growing and the core systems of the companies multiply, this type of API organization is necessary so that our API ecosystem is reusable, agilely modifiable and durable. This approach allows us to have APIs that contain all the business logic, abstracting from both the consumer and the system from which the information is obtained. In addition, changes in legacy systems or consumer systems do not affect the process implemented to a large extent.




Leave a Reply