With the API Management service in Bluemix you can easily manage and monitor APIs. The service can be used as proxy to API implementations where the APIs exposed via the service to developers and the interfaces of the underlaying implementations are essentially identical. Additionally you can assemble new APIs declaratively via a web interface and invoke multiple REST APIs internally before the results are sent to the applications.
This functionality is useful in different scenarios. For example, you can assemble coarse grained APIs to group various API calls before results are sent to mobile clients to reduce the number of network requests. The functionality also allows non-programmers to merge APIs from different providers and massage the data graphically.
Below, I extend the samples from the previous articles where I showed how to develop APIs with Spring Boot and Node.js and how to deploy them to Bluemix as Docker containers. Rather than calling the two hello world REST APIs built via Java and Node, an API client only calls one new API provided by the API Management service.
To learn how to build the hello world APIs check out these articles:
Usage of Swagger 2.0 in Spring Boot Applications to document APIs
Deploying Spring Boot Applications to Bluemix as Docker Containers
Management of APIs with IBM Bluemix
Usage of Swagger in Node.js Applications to document APIs
Deploying APIs built via Node.js to IBM Bluemix
After you’ve defined the API metadata like names, paths and authentication you can choose “Assemble” as the implementation option. In the left column the first two entries define the get requests that are invoked.
Here is how to map the input parameter of the wrapper API with the input parameter of the first get request.
The first get request calls the hello world resource built with Java, the following second one the resource built with Node.
The input parameters are mapped again. Note that you cannot only map from the wrapper API to the second get request, but you can also use the output values of the first get request as input to the second request.
In the last step you define the output of the wrapper API by using (some of the) outputs of the two get requests.
Application developers can try the new API from the developer portal.