APIs are great! That’s for sure! But let’s take a closer look at what a REST API is. It’s an interaction pattern; the way systems can interact with each other.
How do REST APIs work?
To understand it clearly, let’s use an equivalent of human interaction. Here is the “lunch” example.
Someone is asking a question: “What do we eat for lunch?” In REST API wording, the person asking is the “consumer,” and the person answering is the “provider.”
This human interaction matches exactly how a REST API works. And it translates to the following:
Now let’s change the question: “Is lunch ready?”
As the answer is not the expected one, the consumer will continue until they finally receive the expected one. From a human perspective, this situation is quite annoying.
This mimics an API.
Computers are not annoyed, but it’s much more a development effort on the consumer side and a waste of resources on the provider side, often more than they can provide. It doesn’t seem like the “right” solution.
As we all have entered into the data economy with an increasing abundance of data, the more data is produced the more processing and storage are required. In this context, saving resources everywhere possible matters.
REST API limitations
So, what is the difference between these two examples? It’s time!
The value of information decreases over time. But the decrease rate is not the same for all pieces of information.
What about our lunch example?
A menu can be relevant sometime before and even after lunch.
But when you are really hungry, nothing else matters than this “lunch is ready” notification. And once lunch starts, it no longer has any value. What matters is the notification.
There are plenty of examples of this kind, like the stock market, an inventory, or public transport. With a very high value, for a very short time.
A human could ask “When is lunch ready?”
It’s easy for a machine to provide the state of a resource such as “ready/not ready.” But predictions (“ready in 10 minutes”) are rare.
To be relevant, it has to be accurate. What if it is not ready at the estimated time? What if it is ready before? This is a very complex problem. And they’re far simpler ways to handle this.
If we could ask “Tell me when it’s ready,” the problem would be solved.
REST API interaction pattern implies the consumer always initiates interaction with the provider. That’s how it works. So, asking to “know when it’s ready” is not possible with the REST API. Guess what? This is exactly the value provided by event-driven APIs.
Event-driven architecture vs REST
Event-driven API interaction patterns differ from REST API. There are multiple forms, but we will focus on two popular items: Webhook and streaming.
Let’s go back to our “lunch” example. And use our “tell me when it is ready” interaction:
Do you see the difference? Now the provider initiates the event. The consumer has to define an endpoint (i.e. URL) that the provider can call to send the notification to the consumer. The consumer is notified as soon as the piece of information is ready.
This interaction type is referred to as Webhook and is the preferred style for asynchronous API.
This kind of interaction is the essence of Event-driven Architecture.
How event-driven APIs work
Let’s change the provider capability a little. Rather than answering “ready/not ready,” now the answer is the current preparation step.
It’s natural for a machine to tell a resource state.
This would allow another kind of interaction: API Streaming.
And the API version:
The consumer receives each change in state in real-time. Often, Webhook is intended for machines, Streaming is intended for humans.
The issue with real-time information like the stock market is the number of consumers and the pressure on the backend. Certain mechanisms are necessary to provide consumers with the right information, the closest to its event.
Why use event-driven APIs?
Because APIs are great but do not cover all kinds of interactions.
Customers expect a better experience. And time is a critical aspect. As the amount of data increases, event-driven architecture becomes a necessity.
How do you conciliate an API-First strategy with an event-driven architecture approach? With event-driven APIs. Managing both APIs consistently is key to your success.
Discover event-based integration made simple — without getting rid of legacy IT.