As an example I used a simple sample application ‘Approval Requests’ built on the CLEAN stack. The sample is available as open source and comes with several APIs. In this blog article I focus on two of these APIs: 1. Login users, 2. get a list of users which requires user authentication.
The API Connect service basically adds a layer on top of the LoopBack API implementation. Rather than calling the LoopBack APIs directly the APIs of the API Connect service are invoked. This allows the service to track usage of the APIs. Developers can use developer portals, register their applications and subscribe to API plans.
In the sample below I created the API definitions manually via the API Connect dashboard and used a proxy to forward the requests to the actual API implementations. In other words, what I describe here works the same way for other types of API implementations and not just for LoopBack.
First I defined the two paths and their input parameters. In the case of ‘login’ JSON is required which includes an user name and a password. The output is an access_token which is passed to all other API invocations to identify the authenticated user.
The next screenshot shows how to enforce client ids. API consumers get their own client ids when registering applications in the developer portal. With the API Connect service you can also use additionally a client secret.
In the next step I defined the assembly. In my case I simply use a proxy to my LoopBack application. The important parts are the two variables to make sure that the access_tokens are always forwarded and to map the paths defined in the API Connect service to the paths of the underlying API implementations.
In the developer portal API consumers can subscribe to API plans and invoke the two APIs.
API owners can see analytics of their APIs in the API Connect dashboard, for example how many APIs were invoked at which time by which application.