In a comment, Holger Arendt asks me to elaborate on the notion of event notification for RESTful services (a.k.a. resources).
The first and most obvious choice is to simply publish an Atom feed containing an entry for each change. You could also use RSS (but shouldn’t unless you’re happy using underspecified formats.) Alternatively, a proprietary but possibly simpler format could used, containing a record for each change. Those interested in changes simply GET the change feed, i.e. they use polling. No entries will be lost, and caching, ETags/If-Modified-Since and 304 Not Modified mechanics will minimize networks traffic. It’s this approach I was referring to when I said the data access, transaction and event notification interfaces become one in a RESTful architecture: you can use GET for both data access and notifications. And quite often, polling (the HTTP way) is the best approach from a scalability point of view.
Another choice, which avoids polling, would be to keep the HTTP connection open for each “subscribed” client and use this for notification; I’m not a fan of this approach because of scalability issues. (This has recently become known as the Comet approach; earlier examples include mod_pubsub).
Lastly, once could subscribe to changes by sending a URI to the resource to be monitored. The resources store the URI and sends notifications for each change. Examples of this approach are the (expired) Atompub-Notification by James Snell, or the GENA protocol (described in 1998!).
It’s easy to invent a proprietary approach for this, but it would definitely be nice if there were a standard. It’s quite likely there is one (or even many) I have missed, I’m sure my readers will help me out here …
Thank you, this answers the questions i had after reading about the event interface stuff.
We’re also utilizing feeds to give clients access to changes. An additional side-effect is, that in combination with e.g. Firefix 2, one gets a nice styled “gui” for the feeds for free ;-) By providing URLs to related data, a user can then access further information without the need for a special-build client application.
I like the idea of providing a service with some sort of “callback uri” to which changes can be send. This keeps everything more “RESTful”, more uniform. Providing change notifications then becomes just a request to another resource/service - no “break” in the overall architecture, since the receiving endpoint adheres to the same policies/guidelines.