In current technology growth, APIs are the standard for building and connecting modern applications. They provide a standardized interface that masks backend complexity and makes it simple for an enterprise to secure, monitor, and manage how the digital assets it shares are used. Below, we’ll take a look at the differences between RESTful and event-driven APIs, an overview of event-driven architecture, and how to implement event-driven capabilities into existing APIs.
Restful APIs vs. event-driven APIs
RESTful APIs are a well-known architectural style in the API space. Their core principle is that the requestor sends a request message to a replier system that receives and processes the request. If all goes well, the replier system returns a message in response. While this exchange format works well for more structured requests, it limits integrations to those where the expectant system has a clear idea of what it wants from the other.
Example of a typical RESTful flow:
In the case of REST APIs:
Multiple interactions are required from the order in progress until the order is completed.
This is more a development effort on the consumer side and waste or resources on the provider side.
Eventful solutions
In comparison, eventful solutions rely on asynchronous interactions and focus on actions while RESTful systems rely on synchronous interactions and focus on resources. In an event-driven architecture, applications integrate multiple services and products based on event driven interactions. These interactions are driven by event consumers, event emitters, and event channels. Events are typically significant “changes in state” that are produced, published, propagated, detected, or consumed.
That means an event-driven design offers servers the ability to request and respond in real time and do it in a way that provides more flexibility in how data is shared, displayed, and mixed across platforms.
To help visualize how this works, I created a short video with fellow MuleSoft Ambassador Sravan Lingam. This video explains eventful APIs and differences with typical REST-based request-response style interactions which limits their effectiveness for real-time interactions. In summary, event-driven APIs differ from REST APIs by validating a request rather than calling the provider and forcing the consumer to keep checking for a response.
In the case of eventful APIs:
In eventful APIs, a provider initiates the event and the consumer needs to define an endpoint (i.e. URL) that the provider can call to then send the notification to the consumer. The consumer is notified as soon as the piece of information is ready.
Implementing event-driven capabilities through existing APIS
As discussed, eventful APIs provide a better solution, however, this doesn’t mean you will need to build them from scratch. Below, I will share how to implement event-driven capabilities into existing APIs and achieve the desired result.
Before defining and managing event-driven APIs, an enterprise landscape needs to consider several logistical items including:
- API management
- Subscription management
- A logical component to manage the subscription details
- Messaging service which supports pub/sub models
API management is the process of managing externalized events including how the consumers need to consume the events. It’s a combination of Webhooks, event streaming, or the less efficient long polling for a few instances. Anypoint Platform comes with strong API management capabilities for various deployment topologies and ensures every API is secured and governed.
Webhook is a unique URL prepared by the application developer (client) to receive information from an API provider (server) without polling. It is also a technique to push the event to the API provider through a user defined callback URL. Additionally, Webhooks are automated messages sent from the server when an event happens. A call to the URL is made with a payload.
Anypoint Platform helps to derive the event-driven APIs through API management and integration services.
Webhook management in Anypoint Platform:
There are two primary steps to take to implement Webhook management in Anypoint Platform:
- Registering consumer endpoint details through API.
- Pushing the event messages to consumers when the event occurs.
1. Registering consumer endpoint details through API:
In API Manager, create API resources for registering the consumer end points. Then, define callbacks and expose the API to discover and to be consumed by API consumers who are interested to subscribe to those events. As part of registering to subscribe to the events, you need a callback endpoint, event types, and authentication details if any consumer endpoint is needed.
Successful registration generates some unique identifiers for the subscriber (HTTP Code 201 : Subscribed) as shown below:
Mock flow for subscription the consumer:
Similarly, we’ll have one more resource to unsubscribe the consumer, in the case that the registered consumer is no longer interested to listen to the events, an API consumer can go and unsubscribe the events by giving the input of a unique ID which is generated as part of the subscribe resource API.
Mock flow for unsubscribing the consumer:
2. Pushing the events to consumer when the event occurs:
Anypoint Platform comes with strong integration and 250+ of out-of-the-box connectors to integrate with various systems, leverage the connectors, and create Mule Flows to consume the events from the source system and push the messages to registered callback URLs. A simple three-step approach is:
- Listen to the events from the source system.
- Pick the call back URLs to send the event message.
- Send a HTTP POST payload to all the callback URLs.
Summary
In current technology, everything is driven through API and event-driven APIs are very critical for asynchronous functionality, real-time tracking. Anypoint Platform API solution provides capabilities to implement event-driven capabilities through APIs.
Learn more about the power of event-driven design.
