just a headzup in case this is of interest..
Evented APIs
http://www.eventedapi.org/
Overview
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.
.
.
.
From <http://www.eventedapi.org/spec>...
FAQ
The following questions and answers explain some of the nuances of Evented
APIs. Please send additional questions to the authors listed at the top of this
document.
How does an evented API compare with a streaming API?
Streaming APIs typically open a long-lived Web socket to transfer data more or
less continuously. Streaming APIs, such as maintained by Twitter, are an
efficient way to transfer lots of data. For sites with less volume, and
particularly for consuming apps, a streaming API is not very efficient. Evented
APIs are efficient and scale in a well-known, efficient manner. This makes
evented API’s easier to implement, both for the generator and the consumer.
How does an evented API compare with Atom and PubSubHubub (PuSH)?
The complexity of using a distribution hub doesn’t make sense for anything but
large systems. PuSH was a way to reduce polling on the origin server, but it’s
really a stop-gap for better evented systems.
How does an evented API compare with Pushed Data?
Pushed Data, most popularly used by Flickr, is really a simplified form of
PuSH. There isn’t anything wrong with this, but there is value in standardizing
the approach.
How does an evented API compare to webhooks?
Webhooks are used for both events and RPCs, and (intentionally) lack constraint
on how they are used. Evented APIs are only used for transferring events, and
the API allows for a generalized way of transferring events with a common format.
Because of the similarities between webhooks and Evented APIs, you can support
a limited form of an Evented API with a webhook by locking the webhook to a
single event type.
Why use HTTP instead of XMPP or some other notification protocol?
There are several reasons:
1. HTTP is available everywhere online. Very few firewalls block port 80.
2. HTTP is available in almost every programming language, making the use
of event-driven APIs over HTTP accessible.
How much data should be sent as attributes?
It is a good idea to send enough information as event attributes to prevent
common API calls to retrieve additional data. Data that is particularly large
in size, and not always of interest to the receiving party should be made
available through an API. If event consumers must always make an API call to
retrieve additional information, then that information should be included as an
event attribute.
When should the event be sent?
The event should be sent immediately, but there is room for using background
systems to send the events. Simpler systems can simply send the event in the
same thread handling the original request. Most evented systems will operate
fine if the event is sent within a minute of occurring, though faster
transmission might be required for some systems. The exact timing is up to the
generator, who has the best idea of what timing makes sense.
---
End
