When you are looking for an API Management Solution, vendors will bombard you with their product and functionality. Of course, the functionality that they have in place will be in the spotlight. The functionality that is not well implemented, will be more in the background. This is quite normal but requires you to know what you should be looking for to understand whether a product will benefit your organization.
What do you need?
Between all these features from all these vendors and all different kind of possibilities, there are several features that we can deem a must-have when you are looking for an API Management solution. In this blog, I will look at the high-level functionality of an API Management solution and identify what I consider key elements from a general API Management perspective. It’s up to you to decide which of these are important to your organization.
1. Manage the lifecycle
The first thing that I would put on my top five list would be the possibility to manage an API lifecycle. Let me explain a little bit about my thoughts on this topic. An API is, as I often say, the gateway or front door to the products and services that you are offering as an API. If we take the concept of front door literally, you know that every now and then the door needs a little bit paint, perhaps needs new hinges, or a new door lock.
For APIs, the same is true. APIs have a life cycle that they go through. The speed of the life cycle process will be defined per API and is dependent on many factors that have to do with your internal organization, but also with your users and the kinds of APIs that you are that you are offering.
The possibility to actively manage the lifecycle, by moving an API from one phase into another, I would say is key. The first phase is the creation of the API followed by publishing the API and eventually it is deprecated. These phases are vitally important to maintain control over the APIs that you are offering.
Control over the APIs lifecycle also means control over its use by your consumers, whether they are internal or external consumers doesn’t really matter. There is much more that I can tell you about this, but I want to keep the blog short(ish).
2. Resources and bundles
The second must-have, has to do with defining resources. And with resources, I do not mean the resources inside of the API, but I mean the resources in your IT landscape. Because your server will not scale to infinity if the number of API calls increase. What you want is a system that will allow you to assign a quota per time range to the allowed number of API invocations for users or user groups. The API can then only be invoked up to a defined maximum number of requests before access is prohibited for the user or user group.
It is pretty much the same with the call- or dataplan on your mobile phone contract. You have several calls that you can make and data that you can use or text messages that you can send. If you exceed your bundle, you are either cut off or you are set on a lower speed plan so that you still do have connectivity but with a lower bandwidth. Telco’s can do that because, you as an individual customer or user, are not able to use all the available bandwidth of the mobile phone spectrum. However, there is a reason why not all subscriptions are unlimited and that has to do with the available bandwidth. At one point, the mobile phone operator has a cutoff point where they say, this is the maximum that the network can support.
The possibility to individually assign quotas of invocations to users, in combination with a circuit breaker that will be triggered when the total number of invocations exceeds a preset limit, is function number two that I believe, an API Management Solution must have.
3. Analytics / Monitoring
Third on my list is the analytics part of API Management. I mean the possibility to analyze the invocations of APIs and monitor its use. But also, analyzing stuff, like for instance response times, and other things that I would group in the “not seen before” category is interesting to get insights in so that we can detect deviations from the normal operations. For instance: you know what your average load of API Management will be if you have an analytics solution in place. What a good solution will do is that it will tell you, when you see a spike in traffic. For instance, one of your services has just been discovered by a developer that writes a blog about it and suddenly it looks like the whole world is trying to invoke your API.
That is the positive scenario. It can also be that someone is either making a mess of the invocations or that you are part of a targeted attack on your API Management solution. Remember, APIs are the gateway to your organization and if that gateway is not locked and protecting you in a proper way then bad guys hackers or whatever will surely try to gain access to your APIs and see if they are able to enter you IT landscape.
4. Security and access control
The fourth and penultimate category has to do with security and as part of that, access control. Whatever your organization is about, whatever you are offering, there are very good reasons why you want security to be part of your APIs that you are offering. API Security will make sure that only those people who have a legitimate access to your APIs have access to it. Of course, in combination with the quotas on API invocations. Continuing with the front-door analogy, to give someone access they need a key, if you give people access to your API, they’ll also need a a key (or in this case its called an access-token).
The analogy of the front door is a very good one because if I give a person a real key to my front door, he or she would be able to make a copy and gain access until I change the lock. It is for that reason that a lot of hotels switched to plastic key cards, years ago already, with a magnetic stripe or chip that they can program and allows them to digitally switch the lock in case of payment problems or when the key card is stolen. The API key or token should have the same functionality.
Furthermore, we live in a world where we basically Trust No One. We worked with the concept of a circle of trust inside organizations but we tend to go more and more to an environment where validation of trust is preferred, for instance through the a requirement to use a secure connection and by validating the request for proper syntax and semantics. Security does not only have to do with allowing access or access delegation and stuff like that, but also the way the API connects securely to a specific back end system and whether the request itself is not violating any security guidelines. If you want to learn more about API Security, join our API Security webinar.
5. Façade and Integration
Finally, the feature to use the API Manager as your frontend to a whole enterprise wide IT environment. Consider the API Manager solution as a gatekeeper, taking care of who has access and who has not but also quickly sending controlled traffic to an integration layer or backend system. You’ll want to prevent the the API Manager to become a bottleneck and it must quickly forward allowed requests to internal systems or deny invalid requests at the gateway. This will keep your IT-environment (when well architected and setup) performant and safe.
This list of five major requirements is not complete. I could easily extend it and talk about on-premise or cloud deployment models and so on. You will have requirements from your organization and you need to make a well discussed decision about which vendor or product should be on the shortlist.
If you will allow me to make a recommendation, please look at our Advanced API Management guide that elaborates on the topics discussed here and will help you narrow down your shortlist and to have a clear understanding on what to look for when selecting API Integration technology.