We hope you are now convinced Event-Driven APIs matter! If not yet, please click HERE.
So, let’s assume now you have Event-driven APIs and they work as intended. So, the next question is: How to manage them? This is answered by an “Event-driven API Management” solution.
Event-driven API Management expectations
What can we expect more precisely?
- To consume Event-driven APIs easily.
- Generate Event-driven APIs easily.
- Manage Event-driven APIs easily.
- Integrate with ecosystem and security.
- Monitor activity.
Consume Event-driven APIs easily
The heart of a good API strategy is API consumption. The consumer experience is the following:
What to expect for Event-driven APIs? The same as classic APIs!
Webhook implies a subscription mechanism. And it is provided as a REST API. It is manageable like any other REST API. SSE is consumed differently than REST, but endpoint can still be listed similarly in the catalog. So, discovery is the same. Subscription and all other capabilities would also be expected to be the same.
Event-driven APIs must be consumed easily, so like REST APIs and with the same tools as REST APIs. Event-driven APIs must be consumable from an API Portal.
Generate Event-driven APIs easily
Before consuming Event-driven APIs, they must exist. There is a need for a product to generate Event-driven APIs and run them — the Event-driven API engine.
Expectations are to have some UIs for human interactions and APIs for automated interactions to generate Event-driven API from the engine.
We expect Event-driven APIs created to be automatically registered in the API Catalog.
But more can be expected. What if Event-Driven APIs could be generated from APIs, located in the API Catalog?
Let’s take back our lunch example. Consumers want to know as soon as possible when lunch is ready. Without an Event-driven API, every consumer poll the “Is lunch ready?” API. A waste of resources and more efforts to consumers. With Webhook, consumers can subscribe and get the notification, at the right time. Behind the hood, the Event-driven API engine is polling the “Is lunch ready?”, compare previous and current response and notifies each change. So, the API “Is lunch ready?” is used to provide an Event-driven API “lunch notification.”
Our example was about Webhook, but it works the same for streaming. We want to generate Event-driven interactions from existing API, directly from the catalog.
Polling is a way to use an existing API. Another possibility is for the Event-driven engine to provide endpoints and have them exposed in API Management. Combining endpoint and Webhook, publish/subscribe API becomes a reality!
Manage Event-driven APIs easily
This one is simple. If Event-driven API is an API entry in the API Catalog, then it can be managed like any other Event-driven API entry — with a lifecycle. In fact, the term FLAM stands for Full Lifecycle API Management.
Integrate with ecosystem and security
Of course, Event-driven API must be integrated with the ecosystem and the security.
Examples: polling is naturally done with a GET. But what if the API request to POST search parameters? Or if the response requires mediation. Or if a custom authentication mechanism is required?
There are many other examples. Integration and security are tough topics.
The obvious answer: let’s have an Event-driven API engine doing it! Sure, but this is still a lot of capabilities, and quite far from its core value. A smart solution is to have “something else” taking care of the mediated and security and has the engine consuming these mediated APIs.
Something capable, like an API Management solution. These capabilities are not required for the Event-driven API engine if another solution provides it.
Monitor activity
For any management product, visibility is a critical topic.
It starts with monitoring, answering the questions “Does it work?”, “Do I have failures?”, “What are my issues”?
But like APIs, the most important question is about how APIs are used and how to improve consumption.
Event-driven API Management solutions by Axway
Events and Event-driven APIs are important concerns for many companies and the next step in their digital transformation. The event-driven architecture is an attractive approach.
Axway is about to release AMPLIFY™ Streams v2, an Event Hub that makes it easy to exchange messages/events between your (micro)services and ecosystem thanks to modern Event-Driven APIs. It can generate and run Event-driven APIs. But how do you manage them?
We used the exact approach described here and wondered what our customer’s expectations could be. Combining AMPLIFY Streams v2 and AMPLIFY™ API Management, and adding some AMPLIFY API Management configuration, to provide a seamless experience.
For example, there is an inventory API. Classical API Management experience is the following:
Now let’s say we want to provide the Webhook capability to this inventory API. Rather than doing request/response, a consumer can subscribe to receive a notification on changes.
Did you see the differences? In step 2, there are options to set in the API. If “Streamification” is activated, at publish time, an Event-Driven API is generated, and the Webhook subscription API is added in the catalog. Consumers can interact with it in API Portal and use Try-IT to subscribe to the endpoint. It works as expected at runtime (i.e., notifications are sent).
Let’s review all that Axway can provide regarding all expectations.
Generate Event-driven APIs easily:
- From API Catalog: select a base API, set options (as additional attributes or tag), and publish it.
- From Streams API: when Event-Driven API is created on Streams, entries are automatically added in API Catalog.
- As API Catalog entries are generated, API Management capabilities apply to them naturally.
Manage Event-driven APIs easily
An Event-driven catalog entry can be edited, for documentation or an authentication mechanism.
Lifecycle applies for the same Event-Driven catalog entries (unpublish, publish, deprecated, retired…).
Consume Event-driven APIs easily
An Event-driven catalog entry can be discovered exactly like a REST catalog entry.
API Portal catalog can be customized easily. It is possible to have one tab for REST API and another for Event-driven API.
Customer registry (i.e., application creation and credentials self-service) can be used the same way.
Additionally, API Portal collaboration capabilities can be used the same way.
Integrate with ecosystem and security
AMPLIFY API Management is very strong for integration and security, thanks to its Policy technology.
Do you want to make an Event-Driven API from a JMS queue? You can create a policy, expose it as an API in Catalog, and then generate an Event-Driven API from it.
Security policy can be applied as well. Streams v2 Admin APIs are virtualized by APIM and so secured.
Monitor activity
Streams v2 generate API traffic (polling, Webhook notification…). It is possible to have the whole traffic going through API Management, maintaining the paradigm “Whole API traffic goes through API infrastructure.”
Do you want to see it in action? Look for our next posts!
A word about Axway products
AMPLIFY™ Streams
AMPLIFY Streams v2 is an Event Hub that makes it easy to exchange messages/events between your microservices and ecosystem thanks to modern Event-Driven APIs.
Streams v2 is the engine providing Event-Driven API to the AMPLIFY platform and AMPLIFY Streams v2 manages topics. A topic links one publisher with multiple providers. A publisher is how data is collected. A subscriber is how data is exposed. Please see below publishers (at the top) and subscribers (at the bottom) provided.
Streams v2 is based on an API-First approach so APIs are provided to manage it. Streams v2 is Cloud-native and deployed in production in a Kubernetes cluster.
AMPLIFY™ API Management
AMPLIFY API Management is a solution to manage APIs. It provides Full Lifecycle API Management, with an API Catalog and a consumer registry. An API Portal and Analytics capabilities are also included which provides greater security and mediation capabilities.
Download the white paper to learn about navigating the new streaming API landscape.