The explosion of APIs
We are witnessing a huge explosion of APIs, largely driven by a number of factors, including:
- Breaking up the monolith - taking large applications with many services and breaking up those interdependencies into individual, easier to develop and manage standalone services
- Faster innovation - understanding the data demand and providing APIs that support these demands, promoting fail fast and trialing proofs of concept
- Resource sharing - democratizing data and services across departments in an organization
With this immense growth of APIs comes great opportunities, but also, there are some challenges as well.
The challenges of APIs
There are a number of challenges facing organizations as the number of APIs that they develop and deploy increase. Let’s take a look at some of them.
Discoverability
How do developers find these APIs? How do they discover what is available? Where can they locate the documentation? How do they subscribe to the APIs? Ultimately, what does that developer experience look like?
Security and performance
Do you really want to tightly couple authentication and authorization to each API, along with its business logic? How are you going to manage policies on who can access what? Are these policies on an API by API basis, or organizational wide? What about protecting the backend applications? How do you prevent excessive requests to them? What about managing caching and other policies that will not only protect your applications, but also improve performance.
Governance
How do ensure the processes around API design and creation are being followed? For example, are the naming conventions being followed? Are the right stakeholders involved? How are existing services and functions being used?
Monitoring and alerting
Who is using your APIs? How do you know when and where they’re being accessed? Are they being used at all?! Are your APIs and the systems behind them still responsive? How do you check for unusual or suspicious behavior?
Changing the mindset
So how do we address and support the rise of APIs?. First of all, we need to start thinking about APIs as a product. Historically, the attention would be focussed on building the application itself, and then addressing how the application would work with other ones would come last. Changing that mindset to thinking about the API as a product, and designing the API first brings a number of benefits. The journey starts with considering who is going to use the API, what services will it be providing access to, and so forth. This practice of putting the API development ahead of the rest of the application is called API First, which we will cover shortly.
Another element to support the rise of APIs is through API Management. API Management allows us to remove the complexity around API development, so that our concern is centered around the building of the API and the supporting business logic, and let something else deal with the security, the governance, the lifecycle management, and so forth.
API and Design First
API First introduces the mindset of treating your APIs as products. This involves considering the APIs to have equal importance as the application itself. They are viewed as the doorway to the products and services your project is going to provide, and become the first consideration. Regardless of what happens with the project, ultimately everything is going to be using the APIs, so the thinking starts there. It is the component that’s most likely to change if an application, ‘bottom-up approach’ is taken instead. API First allows us to get feedback from all of the key stakeholders, as well as iterating on designs quickly and getting buy-in. Once there is agreement from across the board, everything else can follow in turn.
However, API first is not designed first. There are subtle differences between Code First and Design First in the terms of API first. Code First delivers the API first, with all other activities based on consuming the API coming after. Design First seeks to get a consensus on the API contract, allowing for parallel development based on what the API will look like. My colleague Lorie Pisicchio goes into more detail on this, based on her fantastic blog, as well as a talk she did for API World 2021. Do check them out!
Introducing API Management
API management is a methodology to manage the complete lifecycle of APIs. As well as being a methodology, there are platforms and tools to assist in its application and governance.
There can sometimes be confusion between API Management and an API Gateway. An API Gateway brokers the connection between a client and the API and its backend. It will apply any policies on the request and response flows, such as rate limiting, throttling and transformation. API Management would, as part of the process, determine what policies should be applied, as well as maintaining the historical records of changes made as part of the API lifecycle.
A simple analogy would be as follows - imagine an automated rotating door (the API) between the outside and inside a building, housed within a frame with the mechanics (the API Gateway). The door may revolve at a certain speed (a throttling policy) along with other constraints, however the decision for what rate the door will rotate, and that there’s a rotating door rather than an automatic sliding door, or a hinged, manual door, as well as how it would be installed, and what processes are used to maintain it, was made at the time of building planning (API Management). A decision could be made to speed up or slow down the doors could be made (API Management), as well as whether to remove the doors completely and use a different type, including overseeing the removal and installation (API Management).
So let’s investigate what API Management offers us in terms of dealing with APIs. First of all, there's no point in having an API if a developer can't find it. API Management helps us to not only create APIs, but also publish the APIs and make them discoverable to developers, as well as providing the documentation and other associated information. We can also use information as the APIs are being subscribed and used to nurture the developer community, as well as understanding how they’re using them, getting their feedback, and ultimately, improving the developer experience.
API management also helps enforce the use of policies and controlling access to APIs. So we can deal with whether a client has been authorized or authenticated to use it.We can apply performance policies such as rate limiting and throttling to not only protect against malicious behavior, but to also look after the backend systems.
We can monitor and analyze how APIs are being used, if they’re being used, as well as checking on the health of our APIs. We can also proactively look out for unusual or suspicious behavior and act accordingly, triggering alerts as appropriate.
Last but not least, API management can help us with governance, for example company wide policies, naming conventions, design conventions and so forth.
All in all, API management relieves us from the infrastructure logistics involved in making APIs available, and allows us to apply our focus on the business logic contained within the API management itself. Let’s now have a look at an example API Management platform, Gravitee, an open source product.
Overview of an example API Management platform
Gravitee is a fully open source, low code, highly customisable API management platform, with a highly performant API gateway. It is a Java based product using the Vert.x framework. It uses the concepts of plugins to manage policies, including security, data transformation, protocol mediation, monitoring, authentication, performance and so forth. There are over 100 plugins available, and should you happen to not find the one you’re looking for, you can write your own.
Developer Portal
The developer portal is where developers can explore, research and subscribe to your APIs. They are able to try out the API's, read the documentation, as well as providing reviews and feedback.
API Console
This is where the API owner can manage the whole lifecycle of the API from design, deployment, policies to apply, API deprecation and disablement. They are also able to monitor API activity. There is also an API available for CI/CD deployments and other automation.
API Gateway
The Gateway is responsible for being the doorway between the client and the API. It will apply the policies as dictated by the API Console, and all of the rules applied will be deployed onto the Gateway by the Console.
If you’d like to have a go at getting the Gravitee APIM platform up and running on your local machine, this blog post provides you with step by step instructions.
Wrapping up
Hopefully, you now have a good overview of what API Management does, the difference between API Management and API Gateways, as well as the opportunity to get an example of an API Management platform that can support this practice.If you’ve got any questions about either Gravitee, or API Management in general, do reach out to us on our community forum.
Top comments (0)