Event-driven API Management — Change data capture

We previously introduced why Event-driven APIs matter on the blog. Then, last week, I introduced the need for Event-Driven API Management, what capabilities are expected, and how Axway can help.

To make it short, Event-Driven API Management is the combination of AMPLIFY™ API Management and AMPLIFY™ Streams v2, with some configuration for seamless integration.

Let see Event-Driven API Management in action!

This our first example: Use a webhook to receive notifications for each change. Or a better name: Change Data Capture.

Use case

Let’s use the very well-known Petstore API, from swagger.io. This way, it’s clear this could work for any API!

Petstore API has many methods, especially one method to add a pet and another to find available pets.

Our application needs to know when a new pet is available. Since it is a remote service, there is no way to modify the service or to handle the other consumers. The only viable solution is to do frequent polling to get “fresh” news.

However, this is sub-optimal for many reasons. Firstly, the application will need to keep a copy of the previous response to deduce the differences. That seems doable but several technical details need to be addressed.

Next, each consumer would have to do it on its own; and that’s not consumer-friendly. Finally, from the service’s perspective, this causes a lot of polling and waste of resources.

So, thanks to Event-driven API Management (EDAM), we can generate a webhook from a REST API:

The application can now simply subscribe to the webhook and receive notifications.

Yes, there is still polling, but only by one consumer (EDAM), even if there are 1,000s of subscribers.

How does it work?

There are 3 steps:

• API Manager Admin phase: APIM Admin virtualizes Petstore API, set options, and generates a Petstore webhook subscription API.
• App developer phase: App developer connects to the API Portal, looks for the webhook subscription API, registers the application.
• Runtime phase: All interactions are visible through APIM monitoring. When a change occurs, Streams v2 detects it and sends a notification over the webhook.

API Manager Admin phase

APIM Admin virtualizes the Petstore API, like any REST API.

APIM opens the API, goes to the “API” tab and finds the following panel:

APIM Admin uses it to define whether and how an Event-driven API is generated. The “whether” is the “Streamification?” checkbox. The “how” are all other boxes. Especially, “Subscriber: Webhook” and “Publisher: Polling” being set up here.

API is published to generate an Event-driven API.

Streams v2 is called to generate the correct objects for the Event-driven API, and a new entry is added in API Catalog.

Now, we have this new Petstore_async API! It was even automatically granted to the right organization!

Let see how it will be used.

App developer phase

Let’s switch user and show the App Developer point of view.

The App Developer connects to API Portal.

With API Portal customization capability, it is possible to create a dedicated catalog for all Event-driven APIs, based on tag filtering. This way, it is simpler to find Event-driven APIs.

This webhook subscription API is like any other: documentation, subscription, Try-It, monitoring…

Let see API documentation in details:

This API is very simple to consume. Options were set so two methods of the base API are available for the webhook: getInventory, findPetsbyStatus.

For each base API method, there are three methods on this subscription: create, read, delete.

So, the next step is to subscribe to the application. It can be done with any REST tester, but also directly from API Portal with the Try-It. In this case, the API Key is required.

And done!

Runtime phase

During runtime, the application receives the notification. The best way to track it is through API Management monitoring capabilities.

All polling calls are done by Streams v2 and tracked in APIM since the base API is in the catalog.

Let’s change the monitoring filter to look at our webhook notifications. At subscription time, one notification is sent:

Data sent is with all the pets available. This is the full view.

Later on, a consumer adds a new pet.

What we have is only the notification of this new pet.

That’s great! This is exactly what the application wanted!

Would you prefer to get all the pets available? It is up to you, as that is one of the features and the configurable option of Streams.

Let summarize

Do you want to provide a webhook for an API? This is very simple with Event-driven API Management!

• Virtualize an API and set options to generate an Event-driven API.
• Consume webhook subscription API like any other.
• Monitor all interactions with standard APIM capabilities.

This capability can be very handy to integrate an API-First strategy within an Event-driven architecture.