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 …