We can all agree that services should have APIs. APIs allow for data to be moved in and out of the systems we use, and we all benefit from data mashups. APIs have busted the data silo problem, and it's time to solve the next problem:
Silos of Interaction
Though data is available outside the system, APIs only allow us to discover data after it has happened. The importance of real-time data has led to the practice of polling APIs to discver new data in a timely way.
Streaming APIs?
Perhaps the best known example of real-time data is that provided by Twitter. To access this real time data, you connect to their service and maintain a socket connection. Data is sent over this socket connection, and if the socket drops, you must immediately reconnect. This pattern is not efficient for medium or low bandwidth data connections, either for the producing or consuming party. Receiving a few notifications per day shouldn't be this hard.
Think Events
The notifications that will power the Live Web are better described as events, rather then pushed data. Events contain data, but more specifically describe changes in state. When a record changes in a database, an event will contain the changes made, not simply a copy of the updated record.
Understanding events is an important step to seeing how the Internet will bring us into the future. These ideas are becoming popular for an important reason. Eric Schmidt calls them alerts. Events are the glue that make Benioff's Social Products work together. (For more in that vein, read Phil's Facebook of Things.) While they are using different words, what they are describing is the fundamental concept of an event.
Enter the Evented API
Phil Windley and I have put together a spec for what we call the Evented API. This is a method of registering for and transmitting events in a common format. It is build upon HTTP, and is designed to be easy to impliment on both the generator side and the consumer side. It is technology agnostic (though Kynetx is of course a good choice) and a simple consumer can be easily created using any web technology.
In addition to the spec, we've produced an example event generator and an example event consumer. These tools can be used to test EventedAPI implimentations, or used together to understand how it works.
Read more about this on Phil's Blog.
