apiman.io – open source integration exchange API gateway
First, I'll tell you about the problem. Our company needed an external gateway to redirect API requests from partners to various applications within the company.
Requests need to be sent for different tasks. One of them is the integration of external warehouse systems (WMS).
Basic requirements for the gateway:
The gateway should allow you to configure access to the company's API for various partners. Partners may have access to a different set of APIs.
The gateway must recognize a specific partner and pass its code (or name) on to the application within the company that processes the request. For example, the code of the warehouse performing the shipment.
The gateway must provide at least minimal statistics of processed requests.
The apiman.io product was chosen because it is open source and does not have any restrictions on use.
I’ll say right away that although the product worked, the feeling from it was twofold, so it would be very interesting to know the opinion and experience of other participants in the hub, if anyone has such experience.
I had to tinker with the deployment. It was necessary to configure Keycloak and Apiman to work together (the documentation describes the setup process is not entirely clear). Keycloak in our case is needed only for admin access and interaction of Apiman components itself, because external clients are authorized using the key in the URL.
The product itself, however, as conceived by the developers, is intended to be a system for the interaction of several roles: administrator, organization manager, API developer, partner developer. Integrating Keycloak for admin access looks like overkill, but there’s no way around it.
I will describe the structure and capabilities of this product. It must be said that the structure is complex and has many abstract objects, the purpose of which is unclear. We had to redo the configuration a couple of times before we understood what was what in our case.
1) Organizations – You can create several organizations. In our case, there is only one for now.
2) Plans – a certain set of settings that can be used inside the API. In our case, it corresponds to the list of internal systems and contains the login for internal authorization.
3) API – Each organization has its own set of APIs. The API has a name and an external address. The settings indicate the internal address to which the request should be routed. For each API, you need to specify a plan (i.e., in our case, the internal system).
The API has versions that are specified as part of the address. It is very inconvenient that you cannot edit old versions of the API, but only create new versions. To edit parameters without changing the version, you have to delete the API and create it again. (why they did this is a mystery).
The external API address looks something like this: https://your_host/apiman-gateway/organization/API_name/1.0?apikey=client_application_access_code
4) Client Applications – a partner who uses the API. The set of available APIs is written in the form of contracts (i.e., essentially these are access rights). For the client application, we write a rule to add the code (or name) of the partner to the header so that the internal application can identify it as a specific partner.
5) Gateways – in theory, Apiman supports work through multiple gateways. We use one gateway.
6) Roles – allows you to create separate roles for API developers and for developers on the partner side. I don’t know if it’s possible to use in practice, because… This configuration option was not required. In general, the product includes a portal for partners, which we were unable to configure due to errors. It looks like the portal has not yet been completed by the apiman developers (although I may be wrong).
7) Metrics – you can view a graph with the number of successful and unsuccessful requests to each API in the context of client applications.
8) Politicians – some additional rules that can be attached to the plan or directly to the API. For example, you can enter “Header Rewrite Policy” to add the desired header with the partner code. There is also a “Log Headers Policy”, which allows you to add request and response headers to the log.
Here is a screenshot of the general application menu and the items that are available for a specific API:
This is what the statistics look like. (In this example, there were application access failures due to network problems, which can be seen in the graph):
Based on the results of several months of use, we can say that Apiman works stably.
It is also clear that the product is being developed and, perhaps, in the near future it will be finalized in terms of documentation, and the Developer Portal will also be completed.
