APIs en API Management

“Software is eating the world” said someone who is much smarter than me, now about 10 years ago … During the corona crisis, many companies were again pushed to the facts and they realize all too well that there is still more efforts should be made to digitize their current services. So CIOs, IT managers, etc. everywhere are therefore given the task to speed up the digitization, modernization and innovation of all kinds of processes and applications. But often there are a number of elephants in the room. Cumbersome, old-school applications that have been supporting processes for years, which may not immediately be super sexy but still “work”. Especially internal users who have been working with it for years no longer see the flaws and are “satisfied” with the applications. Read: they have given up on passing on the issues they experience. New internal users are still struggling in the beginning and will try first. At best, they will meekly follow and use the application without further grumbling. In the worst case, they drop out.

Application innovation, digital transformation and other nice terms are now being presented as the solution for those elephants in the room. Easier said than done of course. How do you get started and which components are relevant in this transition. In this blog I would like to take out one component that should definitely be on the roadmap: APIs and the related API management. APIs are one of the most important building blocks that can help you with application innovation. By starting with certain data or even making functionalities of existing applications available to other applications, this in turn can lead to an approach to quietly phase out the old elephants. As with all IT components, governance is also of great importance with APIs. API management tools are the answer here.

What is API management?

I think it is no longer necessary to advocate the use of APIs in 2020. But still, for those few who still need a little push, I refer to the Amazon API mandate of Jef Bezos, who turned his online bookshop into a successful technology-driven company. In short, it means that every team within Amazon must communicate via APIs. Those who don’t will be fired. You can find a reference to the special mandate here. This strategy has led to the AWS (Amazon Web Services) that we now know. An application landscape completely based on APIs.

Managing these APIs (documentation, versioning, authentication, throttling, etc. …) will be quite a challenge with AWS (to use an understatement). The size of AWS and the number of APIs they use will be many times greater than the average company, but the problem is relevant to everyone. How do you ensure that the APIs are only used by the applications you want? How do you gain and maintain insight into its use, how do developers know how to use the API? An API management tool can answer these questions. An API management tool therefore typically consists of the following elements:

• API gateway

  The gateway is the core of API management. It allows for the exposure of the APIs and the routing of the APIs to the backend systems. This component ensures, among other things, securing the APIs (such as the use of tokens, certificates, etc.), limiting the use of the APIs by applying rate limiting, logging all metadata and possibly providing caching for frequently used services. With most gateways there is also a possibility to provide transformations to a lesser or greater extent between the API being exposed and the internal services. For example to convert a json request to an XML format.

• Management portal

  The administration of the APIs is done in a management portal. Various APIs are managed in this portal. It is here where you can group different APIs into logical blocks. These logical blocks can then be managed in their own way. The management of these blocks then boils down to setting and applying policies. A policy is a kind of rule that you want to apply when an API is called. This way you can have different policies executed consecutively. For example, first a check if the client application is not over its rate limit (usually expressed in calls per second) and then a transformation from Json to XML and then calling the backend service. In this portal you will also find all information about the use of the API and you can view the logs.

• Developer portal

  Perhaps one of the features whose importance and usefulness is underestimated is the developer portal. The development portal is the starting point for anyone who wants to use your APIs. Documentation about the authentication, the APIs themselves and other things to ensure that developers can get started with your API. Developers can register an application on this portal that can use the API. Optionally, you can add a payment component if you want to place the API behind a payment wall. Such a portal is useful for external developers, but it is also useful for internal use. Especially if you have different teams, the portal can be a useful tool to ensure that everyone knows what is available in APIs and how to use them to create the right APIX (API Experience).

Why is it (not yet) necessary?

The question “do I need an API management application?” is very similar to the question “to ESB or not to ESB”. Ross Mason drew up a list of when you would want to use an ESB and when not. A number of points on that list also apply to the question of whether you need an API management application or not. The questions to ask are: How many applications will use my APIs? Do I have a complete picture of who is already using my APIs? Can I see how often these are used? Do I know which APIs are available within my company?

If you cannot answer these questions, it might be interesting to look at an API management solution. But maybe not before. If you have a small set of APIs, perfectly documented and only a handful of client applications that you can control yourself, then you can certainly go without. You don’t need an API management solution from day 1. Start small by making sure you are ready to take the step to an API management solution. For example, you can use the Open API spec and embed it in the code. The Open API spec can then easily be displayed in your own portal (or via an application such as swagger UI) and you can add your own documentation. Once the need arises, you can later import it into an API management tool. It is also important that you apply guidelines from the beginning regarding versioning of the APIs, authentication, error handling, etc. Something you will also need when transitioning to an API management solution. Consider the taxonomy. One of the most annoying things is defining objects in an API. From the start it is important to define together with domain experts how the domain model of your business works. Such a domain model then translates into a model that defines what, for example, a customer object looks like. By thinking about this up front, you will save on misery in the long run because everyone speaks the same language and as a result fewer translations and transformations are required.

Conclusion

An API management solution is not necessary in every IT landscape from the start. However, it is important that you keep it on the roadmap and that you think carefully about your API strategy from the start. You can already view a number of solutions for yourself (for example Azure API management) to get a better picture of what such an application can mean and what you can already pay attention to in order to easily integrate the API management tool at a later stage. your landscape.

In the context of application innovation, APIs are one of those foundations that you should set up as well as possible immediately. If you have any questions about this, please let us know.