Alan Chatt, Dale Lane
Managing event interfaces in the same way we manage APIs is a concept we've been thinking about for a while and with the first release of Event Endpoint Management last month we took the first step towards making this a reality.
To introduce the concept of managing event interfaces, we wanted to write about why we view event endpoints as equivalent to APIs, and speculate about why we're seeing rapid growth of event-driven patterns for connecting applications and systems.
APIs and Events
APIs have been with us for a long time and have become the near universal way for applications and systems to interact. However, there are a set of event-driven integration patterns emerging that are equally as important.
To understand why, consider three common types of interaction: requesting action, requesting state, and notification.
Requesting action
Examples:
- "place an order"
- "transfer some money to another account"
In these interactions, we're asking a remote system to perform an action. This fits well with API interactions because we can call an API, and often receive an acknowledgement.
Requesting state
Examples:
- "where is my order?"
- "what's my account balance?"
In these interactions, we expect to get information back from a remote system. It's very common to create an API to facilitate this interaction as well: we call the API and in the response we receive the data we've requested.
This is sufficient for many situations. There are, however, an increasing number of situations where this does not meet our needs; for example, where we need very low latency access to the data we're requesting, or where the volume of requests could overwhelm the backend system.
In such situations, an emerging pattern is to capture changes to the data and publish them as change events onto a topic. Applications that want to access this data can then subscribe to these change events and re-construct a view of the data local to their applications. This is often described as building a "projection" of the data. Every time the data is required, it can be read from the local projection without returning to the backend system. This pattern is described in more detail in our article on "Event stream projections for performant and agile applications".
Notification
Examples:
- "tell me when an order is placed"
- "tell me when my balance changes"
In these interactions, we want to be told when something happens so that we can take an action. Traditionally, to achieve this we would poll APIs and look for changes. This isn't an ideal approach - it requires our application to maintain state between API calls to identify changes and adds unnecessary load to backend systems by repeatedly submitting identical requests.
Event-based approaches, such as web-hook callbacks or, preferably, a messaging system with a topic we can subscribe to, are more efficient ways to support this interaction.
Importance of event-based APIs
As you can see, event-based patterns play an important role in many of the ways we want applications to interact. The adoption of these event-based patterns is being driven by the need to build more applications that react to changes in the world and that are ultra-responsive to users.
As a developer, I already expect to find APIs described and documented in a way that I can discover them. Ideally, I should be able to generate an API key to start using them straight away, which helps to decouple the lifecycle of my application from others I'm interacting with. This is what API management brought to APIs, and why we need the same ability for events.
If you'd like to hear more about this, join our webinar, "Automate your integration - What's new in Cloud Pak for Integration 2021.1.1" on April 15th.
In our next post, we will talk more about how the idea of API management can be applied to events, and how Event Endpoint Management can help manage event sources.