For the last decade, modern web APIs have grown from solutions like Flickr, to robust platforms that generate new business models. Throughout this period of growth, most APIs have been limited to request-response over HTTP. We are now seeing a move back to eventing with the popularity of webhooks to connect SaaS solutions, the introduction of technologies such as Kafka to drive internal messaging, and the need for integrating IoT devices.
API eventing completely changes the way API consumers interact with our APIs, creating new possibilities that request-response cannot. Let’s examine the driving factors contributing to the rise of API eventing in greater detail, along with the opportunities that may inspire you to consider adding API event support to your API.
Why Should Your APIs Support Events?
Reason #1: API Events Drive Innovation
With the introduction of WebHooks into the GitHub platform, software development changed dramatically. Teams were no longer required to explicitly start the build process by clicking a button. The idea of generating daily or hourly builds was a thing of the past. Instead, teams could kickstart the build process whenever new code was pushed to GitHub. Post-commit hooks have always been part of svn and git, but GitHub extended these event streams across the web. Combined with cloud vendor APIs, WebHooks enabled teams to build and deploy their code to any environment of their choosing, all driven by WebHooks.
Reason #2: API Events Enable Collaboration
Messaging platforms such as HipChat and Slack have changed the way team members collaborate. These team messaging platforms have opened up opportunities to integrate bots and command-line automation. The result is a new way to communicate that goes beyond traditional IRC and group chat. To make this work, these platforms offer a combination of request-response APIs and realtime event streaming to enable external apps, bots, and APIs to be integrated seamlessly into their platform.
Reason #3: API Events Drive Codeless Integration
Software-as-a-Service (SaaS) products are increasingly offering APIs for integration. Integration Platform as a Service (iPaaS) tools such as Zapier and IFTTT help connect them together to automate many common tasks without requiring copy-and-paste. Many iPaaS offerings even host the code on your behalf, removing the need to manage servers and infrastructure.
While this kind of integration does not always require writing code, it is limited by the types of triggers offered by an API. When an API only offers request/response support, clients are required to poll to see if there are any changes to important data. With API eventing, these tools can receive a trigger (the event) when data changes and execute the desired automation flow.
Reason #4: API Events Create Architectural Flexibility
More and more teams are exploring microservice architecture as a way to place boundaries around complex solutions, reducing the cognitive load required to understand a portion of the overall solution. All of this is done with the goal of speeding up delivery by being able to create smaller, independent teams that are able to deliver capabilities rapidly. As a result of a loosely coupled microservice architecture, services emit events to inform other microservices of data changes and key business events that drive business workflows.
Additionally, we are seeing the rise of function-as-a-service (FaaS) within the serverless world. Rather than deploying a complete application, smaller functions are deployed and then triggered through message-based events or through API gateways that provide a request/response style invocation.
Bear in mind that messaging brokers such as Kafka, RabbitMQ, or Amazon SNS/SQS are often used to drive microservice events and trigger function-based services. While these are valid solutions for your internal messaging, they are not designed for externalization. If you externalize events, you should consider how your consumers will need to consume them, perhaps with a combination of webhooks, event streaming, or perhaps the less efficient long-polling for some circumstances.
Reason #5: Events Are The Glue For IoT Devices and Edge Computing
Perhaps you have some smart devices around your home or office. These devices often talk to a cloud service to enable visualization of important data and events from the web or a mobile device. Integrating with IoT services via cloud-based APIs offered by vendors benefit from event streaming, as third-party automation solutions can extend the usefulness of these devices.
For some device integration scenarios, network connectivity to cloud resources may not be guaranteed or the amount of data produced may require evaluation and aggregation before being sent to the cloud. This is called ‘edge computing’ and has been commonplace for many years, particularly in manufacturing and the energy industry where high bandwidth isn’t always available.
There are now signs that edge computing will also start to emerge as part of the next generation IoT devices. Event streaming is required for edge devices to integrate with each other and with smart controller devices on local networks. If you are building APIs for IoT, event streaming will be essential to edge communication and computation.
Should Your API Offer Event Subscriptions?
As I have written previously, API events expand the kinds of conversations that our APIs need to have as we use them to solve day-to-day problems. I encourage teams to consider how their API conversations can be enriched through the addition of API events. Without eventing support, APIs are simply left to wait for you to ask them something. With eventing support added, APIs are now able to have a two-way conversation with other APIs and applications. This produces a better user experience and greatly expands your API’s adoption and reduces consumer churn.
