We are very interested in understanding different types of event-driven API architecture available today. As we work to profile the landscape as part of our work on the Streamdata.io API Gallery, we spend a lot of time profiling webhooks, and the event types being used by API providers who are investing more into their event-driven architecture. We find that the API providers who are further along in their journey tend to have webhooks, and provide lists of the types of events that are occurring via their platforms. Demonstrating that they are in touch with the meaningful events that are occurring via their API platform. As we were profiling the service discovery platform Consul, we thought their events API was a simple and interesting blueprint for providing a custom events API with just two endpoints, that allow API users to fire new events, and query the events that have been triggered.
Fire Event
This endpoint triggers a new user event, providing a custom API for executing any types of event that is desired by the API consumer.
PUT /event/fire/:name
Parameters
– name (string: <required>) – Specifies the name of the event to fire. This is specified as part of the URL. This name must not start with an underscore since those are reserved for Consul internally.
– dc (string: “”) – Specifies the datacenter to query. This will default to the datacenter of the agent being queried. This is specified as part of the URL as a query parameter.
– node (string: “”) – Specifies a regular expression to filter by node name. This is specified as part of the URL as a query parameter.
– service (string: “”) – Specifies a regular expression to filter by service name. This is specified as part of the URL as a query parameter.
– tag (string: “”) – Specifies a regular expression to filter by tag. This is specified as part of the URL as a query parameter.
List Events
This endpoint returns the most recent events (up to 256) known by the agent. As a consequence of how the event command works, each agent may have a different view of the events. Events are broadcast using the gossip protocol, so they have no global ordering nor do they make a promise of delivery.
GET /event/list
Parameters
– name (string: <required>) – Specifies the name of the event to filter. This is specified as part of the URL as a query parameter.
– node (string: “”) – Specifies a regular expression to filter by node name. This is specified as part of the URL as a query parameter.
– service (string: “”) – Specifies a regular expression to filter by service name. This is specified as part of the URL as a query parameter.
– tag (string: “”) – Specifies a regular expression to filter by tag. This is specified as part of the URL as a query parameter.
The Consul API provides just these two endpoints, but the results of their usage could make a pretty significant impact on the event-driven architecture for any API platform. Normally we see events being triggered by common read and write evens against existing API resources. This type of custom API allows for consumers to begin defining their own types of events, going beyond the constraints of existing resources. Providing a pretty flexible approach to defining, executing, and working with events that happen across the applications that are developed on top of a platform.
We have profiled the Consul API as part of the Streamdata.io API Gallery, which means we will be providing access to an OpenAPI blueprint for the Consul Events API. Providing a potentially reusable event-driven architectural pattern that anyone could use, even if you aren’t delivering a service discovery API. The pattern is generic enough it could be used on any platform, extending the default set of events, and allow for consumers to define any types of events they want. Adding an important tool to our event-driven architectural toolbox that can make our platforms much more real time, and respond to the meaningful events that occur on a regular basis.
Follow us on social