Category: Open API

API Eventing Is The Next Big Opportunity For API Providers

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.

Tyk joins the Open API Initiative!

Oh frabjous day! This is exciting stuff…

For those of you who don’t know what the OAI is, here’s what they have to say about what APIs represent:

APIs form the connecting glue between modern applications. Nearly every application uses APIs to connect with corporate data sources, third party data services or other applications. Creating an open description format for API services that is vendor neutral, portable and open is critical to accelerating the vision of a truly connected world.

Now, everyone together – what’s the Tyk motto?

Wait, you don’t know it? Shame on you. It’s:

“Connect every system in the world”

Sounds awfully similar amirite?

Bottom line: our goals here at Tyk and the goals of the Open API initiative are very well aligned, as an API Management platform, a lot of the things we end up doing is reading, displaying and interacting with the OpenAPI spec, so it’s very important to us, and our users that we know what’s going on.

We work with a lot of big companies, and we work with a lot of small, fun startups that like to really push the boat out, and every time we see someone talking about another standard, we see the problems caused by the various vendored implementatons (and we’re a vendor!), and by golly, we don’t want to be part of the problem, we want to be part of the solution. Standards make things better – we like standards – and we’re painfully aware of what another standard means to the world of API Description languages:

enter image description here

So we are proud to announce that Tyk is now an official member of the Open API Initiative (OAI) – A Linux foundation collaborative project that is well placed to reduce, rather than proliferate, standards.

The OAI aims to create an open source, technical community where industry participants may easily contribute to and adopt the project’s technology and focus on creating, evolving and promoting a vendor neutral description format currently known as the Swagger Specification.

We are all looking forward to contributing to this project and being a part of reaching our goal.

Scroll to top