APIs, Connectors and Proxies, Oh My!

The AMPLIFY Platform provides several methods for easily connecting to, cataloging, and consuming existing services. Whether you are looking at a cloud service, third-party API, on-prem service or microservice, we’ve got you covered. With the ability to surface services in the AMPLIFY Platform either through an Application Integration Connector or as an API in AMPLIFY Central, which is the best choice?

In this article, we’ll explore both options and determine the best approach.

NOTE: In this post, I’ll be using the Swagger Pet Store API for all examples.

Option 1: Create Application Integration Connector

Use the Build a new connector wizard in AMPLIFY Integration Builder to import a Swagger API. This will generate:

1. A custom connector in Integration Builder
2. An API Proxy in AMPLIFY Central

From Integration Builder, you can create an instance and immediately start consuming the service within a flow or directly invoking the API methods exposed by the connector.

Within AMPLIFY Central, you can optionally choose to deploy the API Proxy and publish it the Catalog. Published proxies can be secured and monitored through AMPLIFY Central.

What is the difference here?

The Connector appears in the Integration Builder list along with all other out-of-the-box connectors, exactly where your integration specialists would look for it when building custom integrations. However, this means anyone who wants to understand how to invoke the connector programmatically must navigate to the Integration Builder, not the AMPLIFY Catalog.

Once an instance of the connector is created from Integration Builder, an API proxy for the connector instance is created and can be found in AMPLIFY Central.

In this scenario, the integration to the back-end Pet Store service was created through an Integration Builder Connector. So, all calls—whether they are made from a Flow that consumes the connector or via the API exposed by the connector or through the API Proxy (if you’ve published it to the Catalog)—will all flow through the Connector.

Why does this matter?

The API exposed by the Integration Builder connector is not controlled by AMPLIFY Central, so it cannot take advantage of the security and monitoring provided by Central. Calls made to the proxy in Central can have policies applied before the connector instance is invoked.

This has the potential to create multiple access patterns, one where calls to the proxy would have policies applied and calls directly to the connector instance would not.

What choice do you make?

If you have an API that will only ever be consumed through Integration Builder, then create the custom connector and don’t publish the proxy generated in AMPLIFY Central. This leaves the Integration Builder as the only access point.

APIs are about providing availability to and driving the consumption of services. In order to achieve this goal, they need to be available to the widest appropriate audience, which brings us to our other option.

Option 2: Import an API Proxy, deploy and publish to the AMPLIFY Catalog

Registering the API in AMPLIFY Central will generate a Proxy, which can be deployed to the Catalog.

Once a proxy is in the catalog, you can retrieve the API’s Swagger document and use it to create a Connector in Integration Builder using the Build a new connector wizard as in the previous section. The difference between this approach and the previous is that all calls to the backend service now flow through AMPLIFY Central, allowing you to leverage additional security and governance capabilities where necessary.

This provides the best of both worlds. Application developers browsing the AMPLIFY Catalog can find the API there, and integration specialists using Integration Builder will see a Connector which they can consume using their normal patterns. Both point to the same API proxy in AMPLIFY Central and are subject to the same governance. One proxy, multiple views for different personas.

Which approach do I choose?

Option 1: Connector first–all requests to back-end services flow through the Connector.

Option 2: API Proxy first–all requests to backend services flow through API Proxy and AMPLIFY Central.

Summary

In this article, we have seen two options for making APIs available for use within Integration Builder, and we have examined how the decision impacts access patterns.

While it is possible to create a custom connector directly from an API definition, doing so short circuits valuable functionality provided by AMPLIFY Central.

Rather than being the primary point of access to an API, Integration Builder should act as a consumer of APIs proxied through AMPLIFY Central and published in the AMPLIFY Catalog. Registering the API through AMPLIFY Central creates a single point of access and delivers management, security, analytics and traffic monitoring for all calls to the API, regardless of whether the consumer is invoking the proxy programmatically or through an Integration Builder connector.