Asynchronous, event-based APIs have been on the rise lately. They’re becoming a popular architectural style to deliver real-time data and evolve the old synchronous, client-server communication standard.

We live in an asynchronous world. And according to Linus Hakansson, Senior Vice President of Product, Gravitee, event-driven architecture (EDA) is the key to this sort of connectivity. Due to their importance, asynchronous APIs deserve the same respect (and best practices) that we give “traditional” APIs.

At Platform Summit 2023, Linus Hakansson from Gravitee will share many tips for event-native API management.

Ahead of this year’s Platform Summit, we’re connecting with a handful of speakers to learn about their upcoming talks and to gather insights on the state of the API economy at large.

Linus Hakansson, one such speaker, held prior architect roles across various cloud and integration technology companies before joining Gravitee. Linus loves to discuss the full API lifecycle, ranging from initial API design to managing and securing API products and services.

I recently queried Hakansson on the state of asynchronous APIs, a theme of his upcoming session. Below, we’ll reprint his thoughts on the state of asynchronous APIs, the relevant event API standards, and tips for managing EDA in practice.

Asynchronous API styles evolve the traditional REST client-server paradigm. Why do you think they are in vogue?

Amazon’s CTO, Dr. Werner Vogels, opened his AWS re:Invent 2022 keynote by stating that “the world is asynchronous,” and he is right. In today’s world, customers expect real-time experiences and updates, and companies need to be able to make real-time decisions to be competitive. A key enabler for that is an event-driven architecture and exposing data in an asynchronous way, and this is where different asynchronous API styles come in.

What sort of technologies make it easier to work with asynchronous or event-driven API styles?

There are a plethora of event broker and publish/subscribe technologies to implement event-driven systems, including Kafka, MQTT, RabbitMQ, Solace, and AWS SQS. Broker technologies can be used to control how messages flow between various products and consumers and translate between various event broker protocols.

However, to expose asynchronous and real-time services to internal or external users, you may need to look at technologies that can deliver the data in a way that is more aligned with web technologies and security mechanisms that are applicable for external consumption. This is where API styles like websockets, server-sent events, HTTP long polling, and webhooks come in.

What are some tips for managing asynchronous APIs?

Treat your asynchronous APIs and traditional APIs (such as REST, SOAP, and GraphQL) equally. This means applying API documentation (such as using AsyncAPI specifications), and making them available in a developer portal for discovery, subscription and performance management.

Think about how your consumers want to consume the data — can they directly access the event broker? Are they able to establish persistent connections with technologies like websockets and server-sent events? Or do they prefer to receive events in a callback manager using webhooks? Maybe your consumers need to consume your asynchronous services using synchronous methods, and you may want to mediate that with something like REST APIs.

Are there any industry standards that make working with asynchronous/event-driven APIs easier?

Two examples are AsyncAPI and CloudEvents. Sharing many objectives and semantics with the OpenAPI specification project, AsyncAPI specifications can help developers create an event-driven architecture based on a contract-first approach. It also serves as the documentation of the event-driven application, explaining how data can be consumed and produced, as well as the data schema associated with the application.

A challenge with event-driven architecture is the variation of event broker technologies and protocols, such as Kafka, MQTT, and AMQP. If you are an application developer looking to consume messages from a broker, you need to care about the protocol and broker technology as part of parsing those messages and applying business logic. Should the producer technology change (for example, from Kafka to MQTT), your implementation logic will likely break as Kafka and MQTT format messages differently. CloudEvents aims to help with this by normalizing event payloads and metadata that producers and consumers can use to ensure logic does not break when the protocol changes.

Why are you excited about the Platform Summit? Assuming you are 😉

I am, indeed! As a Swede, having such a well-represented event in my home country is extra special. I am looking forward to connecting with other industry leaders, thought leaders, and practitioners to learn and share as much as possible!

Without giving away too much else, what can attendees expect to take away from your presentations?

I will be giving two talks. One around the emergence of event-native API management, which helps organizations securely expose and productionize their asynchronous services as event APIs. The second one will focus on open standards in the event-driven space, particularly on CloudEvents, which I introduced above!