Apiman Features

Apiman has a fully-featured API Manager that is decoupled from Apiman's API Gateways. If the Apiman Manager goes down, your gateways can continue running as usual (you can configure your gateways to use a separate data store, too).

Apiman has a rich set of default policies, allowing you to govern and alter traffic transiting the Apiman Gateways in myriad ways. You can also create your own Apiman policy plugins, allowing you to create your own functionality.

See the policies and extensibility sections.

Multiple policies are applied in an ordered chain defined by the user. This means you can combine functionality in the way that makes sense for you. It is also possible for policies to collaborate by passing messages to each other.

Apiman supports multiple versioned plans, allowing you to offer the same APIs with multiple different levels of service. For example, different rate limits for gold vs silver plan.

API consumers (Clients) can subscribe to multiple APIs and get their API keys, plus managing their client's lifecycle (e.g. breaking contracts).

You can attach OpenAPI v2 or v3 schemas (or Swagger), amongst others. Rendered into HTML for API consumers in both the main Apiman Manager UI and the Developer Portal.

Apiman is based around 'organizations', which are similar conceptually to a GitHub org. Users can create and join organizations, and be assigned fine-grained permissions within that org.

Apiman has a hybrid RBAC-ABAC system.

Roles are globally defined personas that are assigned permissions (e.g. 'API Plan Administrator' has a range of plan-related permissions such as planAdmin).

Within an organization, Apiman users are assigned roles that grant them the permissions from that role.

APIs and plans can be exposed read-only to consumers who are not members of an organization. Conceptually, this is similar to a GitHub public repo; people can read and clone, but not modify.

Publish an API without an API key and plan. You can still apply policies directly to the API itself. This feature name is confusingly similar to the previous entry, but is functionally completely different.

Apiman only supports post-hoc billing/monetization via metrics (e.g. Elasticsearch), but has no explicit support currently for up-front billing or payment capture.

Please provide your ideas and feedback in this feature request.

In-browser/API notifications for a range of Apiman events, such as when an API signup needs approval, when someone signs up to an API, etc. Many are interactive, allowing the user to click through into the relevant resource.

We're continuing to add more as we identify useful events to notify users about. Can be disabled.

A fully templated and i18n-compatible email notification system to send a range of important Apiman notifications (subset of those that appear in-browser). Apiman selects the language to use based on the user's locale. Can be disabled.

A new feature in 3.x, Apiman now publishes a range of events into an outbox table. By using CDC software such as Debezium, you can publish these events into event distribution platforms such as Kafka.

These events cover a range of topics, such as important entity state changes (e.g. API publication), and when actionable events occur (e.g. approval required).

You can use Apiman events integrate with external systems, such as business rules engines.

List and search for APIs published in Apiman, including by wildcard patterns (globally and per-organization).

Apiman has a simple JSON-based API Registry capability out of the box to list external APIs that users can import.

By implementing a simple interface, you can interrogate your own registry instead.

Please provide your ideas and feedback in this feature request.

The Apiman Manager's entire configuration can be exported as a JSON file and imported into a fresh Apiman installation. This is useful for backup, upgrades, and migration.

Draft your APIs without publishing them until you are ready.

Create multiple versions of APIs, Plan, and Clients. By default, versions are immutable (i.e. can't change policy configuration).

Create and publish APIs to multiple environments, for example testing vs production.

APIs can be published to one or more gateways/envs. This allows API consumers to find and subscribe to your API via a plan, receiving their API key.

APIs can be retired by the API provider. Retirement revokes access for existing users, and no new subscriptions can be made.

Apiman has simple in-built metrics and visualisations. There are also a range of metrics emitters for the Apiman Gateway, including Elasticsearch, Prometheus, InfluxDB, JDBC, etc. These are commonly combined with visualisation tools such as Kibana and Grafana to provide rich data insights.

Apiman imposes immutability on configurations of published APIs and Plans. This is to ensure that API publishers cannot silently alter the contract established between the API publisher and API consumer (e.g. change rate limits without telling consumer). A new version is usually required.

However, there are some situations where forcing a configuration update may be more appropriate, such as updating endpoints or fixing config mistakes.

Please provide your ideas and feedback in this feature request.

You can set APIs to require manual approval before a subscriber is allowed to use it. This is typically used for APIs that require a due diligence process.

Apiman sends notifications to approvers, and the subscriber receives notifications on acceptance or rejection.

Events are also emitted, if you want to handle this automatically.

Apiman does not have any direct support for mocking at present. However, we are considering integration with Microcks, a comprehensive REST mocking platform.

Please provide your ideas and feedback in this feature request.

Apiman gateways scale independently of the Apiman manager. You can have as many gateways as you need in a group to handle your load.

Apiman's gateways will continue functioning even if the Apiman Manager goes down. They can be configured to have different backing datastores, as well.

You can set up multiple logical groupings of gateways, which you can publish your APIs to independently. This is commonly used to provide development vs production environments or regional segregation.

The Apiman Gateway uses asynchronous patterns throughout its codebase, including policy and component implementations. When you use the Vert.x gateway, then you will get a fully asynchronous experience.

Apiman currently supports Vert.x, WildFly, and Tomcat. Best performance is achieved using Vert.x.

Apiman Gateway can be directly embedded into a Java application by implementing a series of interfaces and components. This requires considerable effort and understanding of the platform, but has been done a number of times.

Standalone Angular application that can be deployed separately from the rest of Apiman. It just needs to be able to speak to the Apiman Manager API.

A range of easy CSS customisations are available to make the devportal match your organisation's look and feel, including colour palate and images.

Simple JSON file-based customisations to change company names, custom links, custom footer, various standard text blocks such as legal prose, etc.

API providers can explicitly choose which APIs and plans to publish to the devportal, and hence can be seen by anonymous users. When a developer is logged in they can see everything their account is entitled to.

Devportal users can be segregated from other Apiman users to limit what they are allowed to do in Apiman. Simply assign the user the devportal role in Keycloak.

APIs can be discovered via searching and lists. You can 'feature' an API to display it more prominently on the front page.

API publishers can provide markdown documentation, which will be rendered in the developer portal alongside rendered any API schema. This commonly used for code samples, example payloads, etc.

You can set a global legal prose that all devportal users have to accept before signing up to an API.

If there is interest, we are considering adding a more fine-grained approach for managing legal prose that is attached to plans or APIs.

Please provide your ideas and feedback in this feature request.

Policies govern traffic transiting the Apiman gateway. For example, rate limiting, security, or header and payload manipulation.

Using simple Java plugins, you can develop your own Apiman policies, enabling almost any kind functionality you can dream of, including schema-based UIs.

Developers can provide a JSON schema with their custom Apiman policies. This allows users to configure your policy in the Apiman Manager UI. Apiman will render the schema into a form, and validate the policy inputs as per your rules.

Apiman has a JUnit-based testing framework to allow robust testing of your custom logic.

All Apiman's components can be replaced dynamically by user-provided plugin implementations simply by referencing your implementation in apiman.properties/conf.json. For example, you could provide a custom rate-limiting component implementation.

Using Apiman's standard plugin format, you can create new components and use them from your Apiman policies.

All Apiman Plugins can be loaded dynamically at runtime, no restart is required. Policy plugins can be managed via the plugins administration page in the Apiman Manager. Component plugins are simply referenced directly in config by their URN.

Apiman plugin policy versions can be upgraded via the API or Apiman Manager administration console.

Apiman plugins can be loaded from (either automatically or via configuration):

• Maven Central
• Any Maven-compatible remote repository, such as Sonatype, JFrog, or Archiva.
• Local ~/.m2.
• User-defined alternative directory.

Local resolution can be useful for 'baking' plugins into containers in immutable architectures.

By implementing a simple interface, you can allow Apiman to search for and import APIs from external API registries.

For example, if you have an API registry inside your organization, your custom Apiman registry could interrogate it, allowing users to quickly import those APIs into Apiman with its implementation details pre-filled.

Apiman captures a rich set of metrics on traffic transiting the Apiman Gateways. A range of metrics implementations are provided out of the box, but you can also implement your own via a plugin.

Apiman is currently primarily an HTTP API gateway. For example, your RESTful Web API will work just fine.

Various protocols can run on top of HTTP, these should also work. Please let us know your results.

Set SOAP type in the implementation tab when defining your API in Apiman.

Apiman does not currently have explicit testing or support for Websockets, but we have been informed that certain setups will work (initial negotiation and handoff by HTTP, rest of connection out-of-band).

If you would like this feature adding, please open a feature request ticket.

If you would like this feature adding, please open a feature request ticket.

If you would like this feature adding, please open a feature request ticket.

This policy enables fine grained authorization to API resources based on authenticated user roles. This policy can be used to control precisely who (authenticated users) are allowed to access the API, at an arbitrarily fine-grained level.

This policy enables HTTP BASIC Authentication on an API. In other words, you can use this policy to require clients to provide HTTP BASIC authentication credentials when making requests to the managed API.

Allows caching of API responses in the Gateway to reduce overall traffic to the back-end API. The Resource Caching Policy can cache requests based on their URL path, http method and specific status code.

The ignored resources policy type enables you to shield some of an API’s resources from being accessed, without blocking access to all the API’s resources.

Allows access to an API’s resources based on the IP address of the client application.

Blocks access to an API’s resources based on the IP address of the client application.

The Quota Policy type performs the same basic functionality as the Rate Limiting policy type, however, the intended use of this policy type is for less fine grained processing (e.g., 10,000 requests per month).

Transfer Quota tracks the number of bytes transferred (either uploaded or downloaded) rather than the total number of requests made.

The Rate Limiting Policy type governs the number of times requests are made to an API within a specified time period.

This policy is used to only allow access to an API during certain times.

Re-write URLs in responses from the back-end API according to patterns provided.

This plugin provides a policy that can help pass the API Key through to the back-end service.

This plugin has policies for performing circuit breaker functionality.

This plugin implements CORS (Cross-origin resource sharing): A method of controlling access to resources outside of an originating domain.

Provides a policy that permits or denies requests matching certain HTTP headers.

Provides a policy which allows security-related HTTP headers to be set, which can help mitigate a range of common security vulnerabilities.

A plugin that contributes a policy that turns a standard RESTful endpoint into a JSONP compatible endpoint.

This plugin offers an OAuth2/JWT authentication policy that leverages the Keycloak SSO platform as the identity and access provider.

Much of its functionality can actually be used by a wider range of SSO providers than just Keycloak.

Roles can be extracted and used with authorization policies, or injected into headers to pass to backend services

A simple generic JWT auth policy (try this is the full-fat Keycloak plugin does not work for you).

A policy that logs the headers to std out. Useful to analyse inbound HTTP traffic to the gateway when added as the first policy in the chain or to analyse outbound HTTP traffic from the gateway when added as the last policy in the chain.

Offers a simple policy that allows request headers to be added or stripped from the HTTP request (outgoing) or HTTP response (incoming).

This plugin provides a very simple policy which can transform the request and/or response payload between XML and JSON.

You can implement your own custom policy plugin using Java.

You can make Apiman do almost anything!

See the extensibility section.

Apiman is supports Keycloak IDM out of the box. This allows a multitude of security, federation, SSO, and user management duties to be delegated to a specialist platform.

Tomcat's simple auth mechanism is supported, but likely quite basic for real deployments. You can substitute it with Keycloak.

Please provide your ideas and feedback in this feature request.