What is API-Led Connectivity? Here is what you need to know about this technology and the key steps to move towards this approach in order to improve your business efficiency.

Nowadays, APIs are everywhere. They are not just a technical interface on top of a legacy system. Today, thanks to the Cloud, they provide new ways of integrating services so that companies can build new businesses and open new opportunities to reach their customers and partners. Furthermore, early adopters may be able to expand revenue by joining forces with other enterprises.

In this article, I’ll give some insights about why this is so important, and I’ll describe the key steps to move towards this approach.

What does API-Led Connectivity mean?

API-Led Connectivity means that all the data and applications will be connected through reusable, well-defined, and documented REST APIs.

These APIs are treated as “first-class citizens” in a way that if they are well-designed, organizations can securely democratize access of assets and operations to either internal or external customers and partners, thereby unlocking new revenue streams. This will allow companies to know the customer better and innovate faster than ever before.

A traditional way of developing software for companies has been to have a backend that implements an API accessible by a frontend. In many cases, the backend is a monolithic application with several layers that finally ends up connecting to a database. However, this approach has a big problem: If the organization needs a new application, a new application should be written. In the best scenario, some components could be imported from the first application.

An API-Led approach means that the backend would be divided into a wide array of Microservices that implement well-defined APIs. This allows teams to construct new applications reusing the Microservices that are already deployed and working in the organization. We have three kinds of APIs.

1.  System Layer APIs

They provide the means of accessing the core systems of the organization and exposing the data in canonical formats. They publish data from systems like ERP, proprietary databases, customer and billing systems, etc. They are managed by IT and should not be exposed for public use outside of the organization.

2.  Process Layer APIs

They are responsible for encapsulating business logic processes. They perform orchestration actions in order to gather, merge, and transform data by calling multiple system APIs. However, these APIs should not be exposed for public use. Once these APIs are defined and deployed, they can be reused whenever necessary.

3.  Experience Layer APIs

They are simple APIs designed to serve information to a specific UI application. They take the information from Process Layer APIs and just transform it so that they can be easily consumed by client applications like mobile apps or web apps. They just expose what is really needed by the client. These APIs are the ones that can be exposed for external use, and they represent the final product of our organization, which can be consumed by customers or partners. As such, we can apply policies such as SLA, since they can be monetized to earn revenue for the organization.

Implementation steps towards API-Led Connectivity

In order to have a successful transformation towards API-Led Connectivity, organizations must perform the following steps.

1.  Design first

This is key! The API design must be done before writing a single line of code. APIs should be designed carefully in order to be consistent and reusable, taking into account the needs of the API consumers.

This is a relatively new approach but is catching on fast, especially with the use of API description formats such as OAS (Swagger) and RAML.

Well-designed APIs have an increased adoption and consumption by API consumers, since they are more consistent, and they require a lower learning curve, thereby reducing the time taken to integrate. Additionally, this has more relevance if your API is going to be used by external customers or partners. Your API becomes a product on its own, and a good design is key for customer satisfaction.

2.  Publish

All APIs should be published into an internal site — let’s call it API Catalog — so that any possible consumer can discover it, analyze it, and in the best case, even try it through a mock server accessible from the Catalog. On this site, API designers can add more documentation and give examples and any other complementary information that might be useful for API consumers to encourage fast adoption. This API Catalog should be able to publish external API definitions to parties outside the company, keeping internal APIs only visible for teams inside the organization.

Once APIs are published, teams can start the implementation of the API client and the API implementation in parallel.

3.  Deploy, Use, and Reuse

Once the implementation is finished and tested, it can be deployed so that consumers can start using it. Developers in other projects can search the APIs in the API Catalog and start using them. Here is where time and money are saved.

4.  Monitor

Instead of exposing the real implementation, organizations can expose API proxies, which allows them to control and monitor the usage of the APIs. They can add several non-functional requirements such as security (e.g., JWT), SLA, logging, whitelists, blacklists, usage analytics, and a long list of many others.

Summing Up

There are several reasons why businesses like yours should consider launching APIs in API-Led Connectivity:

• Less time is needed to market new processes.
• APIs can be published and used by external customers and as such, are monetized.
• Stimulating business and technical innovation may find new ways of using APIs already deployed.
• There is easy integration between backends, processes, and client apps.
• It is easy to scale since each API is a Microservice.

In other words, API-Led Connectivity is changing the way apps are being developed and integrated, providing a better and faster way for communication and sharing data among those apps.

At Hexacta, we have very well-prepared developers and teams that can give value by developing features in all API layers.

Comments?  Contact us for more information. We’ll quickly get back to you with the information you need.