This is a single archived entry from Stefan Tilkov’s blog. For more up-to-date content, check out my author page at INNOQ, which has more information about me and also contains a list of published talks, podcasts, and articles. Or you can check out the full archive.

RESTful Pub/Sub

Stefan Tilkov,

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 …

On July 27, 2007 9:08 PM, holger said:

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.

On August 5, 2007 7:30 AM, Benjamin Carlyle said:

I have one of these that my company uses in-house. I initially developed it in my own time, but was pulled up some time ago in actually releasing it. I haven’t had time to push it through internal processes to get it out there. Personally, I think it is as near to perfect a solution as is technically feasible in the social environment of the Web. I’ll start making noises internally about it again soon, as I think this is key to many REST systems.

Benjamin.

On August 7, 2007 10:58 PM, Stefan Tilkov said:

Ben, that would be more than cool …