Are Streaming APIs Event-Driven By Default?

We were working through some of our profiling of common web APIs today, as well as some of Websocket, webhook, a Kafka APIs. Exploring the differences between APIs that were being profiled as part of the Streamdata.io API Gallery effort. We are working to profile a number of popular web APIs, providing a directory of valuable API resources. These APIs are web APIs, employing a common request and response format, however along the way we are tagging APIs we find that are using Websocket, and other streaming technology, as well as identifying regular web APIs that would make for excellent targets for Streamdata.io to turn into real-time streams.

As we talk about the different ways in which we want to present the APIs, we find ourselves exploring different spectrums that exist between request and response APIs, event-driven APIs, and streaming APIs. I found myself asking, are streaming APIs event-driven? I concluded, yes, all streaming APIs are event-driven, because there has to be some sort of triggering event to tag it for inclusion in the stream. Being added, updated, or some other meaningful event that would push the data or content to be worthy of streaming. The distinguishing characteristic is that the API provider isn’t always showcasing those events as part of the streaming API name or documentation.

After thinking about this, I also asked if all event-driven APIs are streaming, to which the answer is pretty clearly, no. There are many event-driven API implementations that use webhooks, or other non-streaming push technologies. Streaming is really about the transport speed, efficiency, and persistence. As we’ve talked about before, webhooks is really the training wheels for an event-driven API landscape. Helping platforms realize their event-driven potential, mapping out what types of events are occurring the most often, and which ones are the most meaningful to consumers. Developing a map of their APIs event-driven landscape, and building up demand and establishing the need for which topics and resources will be needed to stream and made available in a more persistent manner.

Our profiling of the landscape is helping us properly identify the manner layers of how APIs are being made available. It is also really allowing us to see the untapped potential for applying an event-driven layer to many existing APIs, mapping out the most volatile resources, and the most valuable events. It is helping us understand how to evolve our own roadmap, structure the Streamdata.io API Gallery, as well as help our customers and partners think through their own event-driven API strategy. Even our most seasoned API providers and service providers are working to refine their event-driven API strategy. Something we are here to help with, consulting, and providing workshops and other materials to help folks navigate this fast-moving landscape.