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