Over the past decades, the communication needs of companies have increased significantly. As a direct consequence, the number of systems has exploded. These are no longer confined to the company's internal network, but are distributed over various platforms (e.g. through cloud services).

In order to meet the integration needs between all these actors, the exposure of communication interfaces becomes necessary. These interfaces must be able to integrate with different types of media (mobile, web, application server, etc.).

In the middle of this jungle, the issues of security, visibility and data governance have never been more present.

For companies, it is all about speeding up and creating new products. In an increasingly demanding market, it is necessary for them to create added value more quickly.

All of this necessarily involves opening up the data within the company but also with partners.

This liberation of data can largely rely on the API, which is now the communication standard. However, in order to achieve this opening up, it is necessary to use industrialisation tools that guarantee the quality of all these exchanges.

It is in this context that API Management has a special place.

It is accepted today in modern architectures that exchanges between systems are made via APIs. The latter have solved the problems linked to the heterogeneity of systems by relying mainly on the HTTP standard.

However, implementation, security and deployment are directly dependent on the development teams and can vary greatly.

By leveraging API Management tools, teams will be able to quickly produce APIs that meet quality standards and spend more time on the business logic inherent in the application.

API Management covers a wide range of uses because it operates at several levels:

Beyond the purely technical aspect, API Management allows a more efficient integration between API producers and consumers.

The developer portal is a fundamental component of the platform. It is through this portal that the teams will publish their API catalogue.

By browsing this, consumers have direct access to the documentation and can even test the APIs. Finally, they have secure access to the APIs (see Use Case: Systematically securing the API).

This limits meetings and email exchanges in the integration phases. But if necessary, the developer portal also allows consumers to communicate with API managers (support, enhancement requests, etc.).

In large-scale information systems, it is sometimes difficult to have a clear view of the application landscape. The API catalogue is an efficient way to know what exists.

New ways of consuming services in production can emerge and create added value.

From the start of the project, the API is deployed on the platform and benefits from security standards (OAuth2/ OpenId Connect, SAML, API Key, HMAC). These deployments are generally integrated into the continuous integration chain of the application.

This allows developers to rely on API Management and focus on business processes (the real added value).

It is also an effective way to secure aging applications with obsolete security protocols.

Through the developer portal, consumers have the possibility to request access directly from the API managers.

Thus access control remains the responsibility of the application teams, who have the power to validate (or not) requests.

Once the validation is done, the API Management automatically generates an access (a key or a password depending on the protocol used). In addition, the duration or revocation of the access can be easily managed.

Governance is a perilous subject in large information systems. The same data can come from different sources and it can be difficult to identify who is responsible for it.

Through the developer portal, teams publish their API catalogue and at the same time they define which data types they are responsible for.

By having lifecycle control (from design to consumption) over its APIs, the team is able to identify who is consuming and how. This is one of the most interesting aspects of the solution, as control remains with the application managers.

This can be referred to as an API Management philosophy. For the more mature structures, there is also the "API as a Product" model, which involves numerous roles and the monetisation of APIs.

One of the advantages of API Management is the ability to offload non-business aspects onto the platform. Thus the APIs deployed will automatically benefit from numerous functionalities such as :

Monitoring
Teams can monitor the health, response times, and number of requests received by the API. This data is most often presented in the form of a dashboard containing metrics and graphs.

Logging
The Gateway API collects traffic logs like most proxies. These logs are then consolidated, valued and rendered with tools such as ELK. The latter are generally directly integrated into the API Management solution.

Alerting
If the platform detects unavailability or abnormal response times, the team will be notified.

Security
Securing APIs with different security standards depending on the type of flow (call from a browser, or system to system).

API Management usually integrates with authentication servers (Active Directory, Key Cloak, OpenAM, ...).

Data validation
The content of requests can be validated upstream via validation schemas (JSON or XML). Thus, requests that do not respect the schema are automatically evicted before they reach the application servers.

The Gateway API allows you to distribute the load between your application instances. This distribution can be subject to rules (origin of the request, HTTP header, CORS), so the requests will be addressed to different servers. Similarly, if an instance becomes unavailable, the traffic is automatically redirected to the others.

Some platforms also allow advanced features such as blue-green, canary testing or AB testing strategies. The main idea being to redirect a small part of the traffic to a new version of the application, this technique minimises the impact of incidents during new deployments.

In this logic of giving more autonomy to teams, API Management fits perfectly into the DevOps culture. Where historically, the entry points were managed by the infrastructure domain, the developer can rely on the platform to publish his API while respecting good security practices.

The API must follow the application's life cycle, so the API descriptor (often in OpenAPI format) and configuration are stored and versioned like the application code.

The deployment of the API should be integrated into the integration chain in the same way as the deployment of the application itself.

The integration of such a tool can be daunting as it requires strong adherence, both from a technical and organisational point of view.

It is necessary to clearly define the role of the platform as it can easily conflict with other components. It is not uncommon for teams to limit the scope of functionality to avoid overlap with other tools.

For the solution to really find its audience (consumers and producers), it is necessary for the application teams to fully appropriate the tool.

The main pitfall to avoid is the ESB (Enterprise Service Bus) model where often only one team is responsible for the exchanges between applications. This usually leads to governance problems and slows down projects.

Here we want the developers to remain in control of the data.

That is why it is advisable to have someone who can instil this philosophy and accompany the teams in this transition. Don't hesitate to call on our experts to help you understand these issues and support your teams.

As the opening up of data leads to a sharp increase in the number of APIs, API Management is logically becoming more and more present in large-scale information systems.

The platform brings many technical tools to orchestrate the APIs, but also a governance philosophy.

It can be difficult to determine where its role begins and ends as it covers a wide area, necessary to set a framework for its use.