Posts tagged with plugin
Customising path patterns for your Apiman Gateway
One common request we hear is how to create custom URL patterns for the Apiman Gateway.
For example, this means allowing changing the (Public API) default:
http://gatewayhost:port/{organizationId}/{apiId}/{version}/
To a custom alternative. As a simple example we’re going to hard-code an organisation in. We’ll assume that we’ve established a convention to always publish our APIs to a particular org. That will change the pattern to:
http://gatewayhost:port/{apiId}/{version}/
If you’re using the Vert.x Gateway you should use Apiman 1.4.3.Final or later as a bug prevented plugins from loading from static config. |
Apiman 1.2 - Improvements to Plugin Management
Apiman is not only preconfigured with a rich set of policies that you can use, right out of the box, but, from its earliest releases, apiman has also included a mechanism that you can use to define your own custom policies through plugins. This article describes the improvements introduced in apiman release 1.2.x that enable you to better manage your custom policy plugins.
CORS? Of Course!
If you’re looking to define CORS policies in your API Management layer, then we have an official plugin that should be perfect for the job.
For those unfamiliar with CORS, it’s a way of precisely defining who and how a remote origin may invoke an API’s resources. Generally, due to the same-origin policy, a web browser will only allow the invocation of resources that reside on the same origin as the requesting page. This mitigates a range of malicious script attacks by preventing interaction with remote resources.
However, if we want our resource to be callable by some (or all) other origins, then we need to define a CORS policy which lets user agent know what’s allowed.