Events indicate something has happened. In this they differ from the request-response interaction style popular on the Web. Event-based systems are declarative whereas request-response systems are interrogatory. The difference between events (“this happened”) and requests (“will you do this?”) offers benefits in looser coupling of components as well as semantic encapsulation (see On Hierarchies and Networks for more detail).
APIs have become an economic imperative for many companies. But APIs based solely on request-response style interactions limit integrations to those where one system always knows what it wants from the other. The calling service must script the interaction and the APIs simply follow along.
We envision a world where applications integrate multiple products and services as equals based on event-driven interactions. Event APIs following the form described in this document enable building such applications.
The Evented API specification provides details of how event generators and consumers operate and how event subscription works. All interactions are over HTTP to make the spec as flexible as possible. You can use any language to generate and consume events. We've tried to design the spec so that it is easy to implement--particularly for event generators.
This site has an example event generator and an example event consumer for visualizing how the spec works. Visit the consumer and create a event signal URL, cut and paste it into the event generator, and start playing.
The Evented API specification was developed by Sam Curren and Phil Windley of Kynetx. Kynetx supports the Evented API, but the specification is independent and does not rely on any proprietary technology.