One of my hobbies is photography and when I bought my first camera it was a compact camera. I soon realized and experienced that I needed a reflex camera (SLR), because the resolution, speed and quality was far more better. I did not realize it until I really used the product. The again after a few years I noticed that I did not use my camera a lot. Why was that? Because the camera was pretty big and unpractical to take with me all the time. Then I read about a system camera, which has the advantage of being small, but still has the possibility to switch lenses. I never regretted my choices, because at the time it seemed to be the best choice. Today there are a lot of camera’s with lots of possibilities and specifications. Which one to pick? This depends on a lot of factors. What do you want to photograph with the camera. What type of photographs do you want to take, for example portret-, landscape-, sport- or street photography.

The same holds when you are selecting a software application, in this case an API manager product. In my opinion there are 3 high level options to select a product:

1. Just go with your gut and select one
   Select one based on your feelings (“onderbuikgevoel”)
2. Try-out period
   In this case you try-out a product for a couple of months (POC or pilot). Use it the way you think and start experience the capabilities you really need within your organization.
3. Thorough investigation of capabilities
   Start a trajectory with collecting requirements, making a long-list, making a short-list, arranging demo’s, rating the products, selecting the most suitable, installing- and configuring the product, defining the governance around it and start using it.

The difference with a camera is that you are the only one to decide (most of the time). In case of a software selection, you can be tided by regulations and a lot of other persons have different feelings and meanings. In case you need to go for option 3 this blog will give you 10 categories of requirements to think about.

A camera has several important components, like the body itself, the light sensor and the lens. An API manager also has different logical components which are:

• API Publisher
  A component where APIs are defined, policies are defined and APIs are published to the gateway(s). Also called the control plane of the API management solution.
• API Gateway
  The API gateway is the runtime component that will process the API calls. It will validate the policies that are defined for the API and it is the most important component to secure your api’s to the backend systems.
• API Portal
  The component where consumers can search for APIs, can test the APIs if it fills their needs, read documentation about the non-functional requirements of the API and eventually subscribe to the APIs they want to use.
• API Analytics
  A component to store data about the API usage, metering and monetizing capabilities.

So what are the 10 categories of requirements you need to think about when selecting an API manager? Here we go

1 – API definition

Most of the API Managers will support the contract first paradigm, in which you first define the API and then implement it.

• Do you need the capability to define your API using an editor (for example Swagger(Open API), RAML or a proprietary format)?
• Do you need to import existing API files? Import WSDL?
• Add documentation? Which formats do you want to support for adding documentation?
• Do you want connections to other content management systems?
• Do you need the capability to check for organizational api definition standards?

2 –  API Gateway

• Do you need a separate gateway for internal- and external usage? This can be interested in case the security policies are more strict for external use than for internal use. Or the performance for internal traffic must be different.
• Do you want to have horizontal scalable- and central managed gateways?
• Do you need micro-gateways that are even more distributed than the full blown gateways? Microgateways can be interested for Microservice architectures.
• Do you want mediation capabilities or do you use other products to do the mediation?
• Is the gateway purely used to pass on the messages and only checking the policies?
• Which protocols do you want to support? HTTP or also JMS, MQTT, Websockets or AMQP?

3 – Deployment

The deployment features are important capabilities of the product. There are several possibilities: Cloud (SaaS and/or own DC), on-premise and/or hybrid.

• Do you want to have the flexibility to be cloud agnostic? So a deploying possibility on Google Cloud, but also be able to migrate to AWS or Azure?
• Deploy possibilities on OpenStack, Apache Stratos or docker containers?
• Another important aspect is if the components are loosely coupled. In this case the components are separately deployable and scalable. A gateway may have other scalable requirements than an API portal and also have other availability and security requirements. It is a pre that the API manager product can support this kind of deployment options.
• How is the product handling patches and upgrades? Does it require to shutdown the components or are rolling upgrades possible with zero downtime? Note that this can be more important for the gateway component than for the portal and publisher components.
• What kind of authentication/authorization features do you need?
• Do you need connection to your internal IAM, or maybe even to an external IAM?
• Do you want social authentication possibilities like OpenID and Facebook?
• Do you need multi-tenant support, so that you have clear isolated environments with your own users and access rights?
• In case external database storage is used, which database(s) do you want to be supported?

4 – Policies

There are several categories of policies:

• Traffic/routing policies (i.e. caching and rates/quotas)
• Mediation policies (data mapping)
• Security policies (note: these are described in the security section)
• Extension or custom policies

Next some capabilities to consider:

• How are the policies managed? Are they centrally managed within the API publisher and can they be dynamically updated?
• Can the policies be externally stored in a configuration management tool and integrated within CI/CD street?
• What is the granularity of the policies? For example: on key, subscriber, application, product, API, API
• Is it possible and easy to add custom policies?
• Do you need mediation policies like data- and protocol transformation or is this done by another functional component within your architecture.

5 – Analytics

One of the capabilities of an API manager is the metrics about the API usage. You can think about:

• API usage per subscription, application or API
• API latencies
• API response times
• API errors
• SLA
• Security

The following is a list of features you can think of when analyzing the analytics requirements:

• Some products will have dashboards out-of-the-box which are dynamically updated. Some only have logs on which you can implement your own reports.
• Do you need monetization capabilities or use your own mechanism to implement this?
• Is it possible to define your own custom dashboards and is this easy task?
• Is it possible to export your analytics data and in which formats (for example CSV, XML, PDF, Word)?

Is it possible to automatically export the data to a data lake or 3^rd party analytics (like Splunk or Google analytics) ?

6 – API Portal

The API portal is the frontend for developers and consumers to look for APIs. In fact it is your shop that is the entry point of your API world.

• Should the portal be customizable to your own brand theme?
• What should the access control and visibility of the partner-, public- and internal APIs be ?
• Should it be possible to add your own custom flows or hooks when some important events occur (like a subscription must be approved before it can be used, or some special actions must be taken in case a new application or product is created) ?
• Do you want community support, like discussion forms and FAQs, where consumers can help each other and ask questions? Or maybe enter problem reports in case there are troubles with using the API.
• How fancy do you want to have your sandbox to test APIs?
• Generation of client code for all kind of languages like Python, Node.js, .Net or Java.
• Do you need connection with your own content management system (for example office 365) ?
• Internationalization can also be an important aspect to consider in case you need multilanguage support.
• What should be the search capabilities? Will it only be based on tags or text content, or do you need more fancier capabilities like proposals based on earlier subscriptions?

7 – Product

The price of the product is also important of course, but there are also other very important items to consider (I think even more important):

• How is the support? Is there support within your country and do they speak your language?
• How is the customer base within your country, so that you can learn and ask help from those customers as well. They have already practical experience with the product, so they can indicate where the pitfalls are.
• Do they have a good and clear vision of the product or is it almost end of game. Is there a clear roadmap?

You can also look at the Gartner- and/or Forrester reports of course, but local support can be very vital for your company.

8 – Security

One of the key aspects to buy an API manager is the security of the data and services of your organization. There is a lot to read about this so I only mention a few features to consider.

• Which kind of token support do you want, for example OAuth 2.0, OpenID or normal keys?
• How do you want to protect your backend api implementation and services? For example two-way-ssl, basic authentication or payload encryption (to have end-to-end data security).
• Integration with your internal IAM and/or external IAM system.
• Single-sign-on using SAML tokens.
• Role based access (for example XACML or OAuth 2.0 scopes)
• Black and white listing of IPs, so that only an explicit set of IPs and domains are able to access the APIs.
• The security keys and identities need to be protected too.
• Support of federated identity in the form of JWT.
• VPN connection to your IT servers in case the solution is public Cloud based.
• The product is secured and protected for large payloads, DDOS attacks and SQL injection.
• Is it needed that the product is certified and compliant with a security standard, like PCI DDS, HIPAA, SOC1 and SOC2.

9 – Operations

The last item on the list is how the product is operated.

• Do you need real-time monitoring of your APIs and be proactively alerted in case something happens? Examples are out of resources, APIs are not reachable anymore, the latency becomes too high and SLAs are not met.
• Do you need the possibility to inform users in case the state of an API changes? For example the API will be deprecated or becomes obsolete.
• What are the disaster recovery capabilities and corresponding RTO?

Conclusion

There are a lot of features you have to think about when selecting an API manager. You  can make it as complex as you want. From following your feeling to a full blown project with investigation and analysis trajectories. Take your pick and do what is necessary within your organization.

Further be aware that the API management journey does not end here. Also when you selected your camera you have to use it, start experiencing how to use its functionality in different situations. How the photos are governed and how you setup a whole photo project. You need to define the governance processes around the APIs as well, but that is a whole different story.

Feel free to give feedback on this blog, or contact me when you have questions and remarks, or if I can help you with the process!