How would I create an asynchronous notification system using RESTful web services?

Question

I have a Java application which I make available via RESTful web services. I want to create a mechanism so clients can register for notifications of events. The rub is that th

Answer 1

In the response to the RESTful request, you could supply an individualized RESTful URL that the client can monitor for updates.

That is, you have one URL (/Signup.htm, say), that accepts the client's information (id if appropriate, id of object to monitor) and returns a customized url (/Monitor/XYZPDQ), where XYZPDQ is a UUID created for that particular client. The client can poll that customized URL at some interval, and it will receive a notification if the update occurs.

If you don't care about who the client is (and don't want to create so many UUIDs) you could just have separate RESTful URLs for each object that might want to be monitored, and the "signup" URL would just return the correct one.

As John Saunders says, you can't really do a more straightforward publish/subscribe via HTTP.

Answer 2

If polling is not acceptable I would consider using web-sockets (e.g. see here). Though to be honest I like the idea suggested by user189423 of multipart content-type or chunked transfer-encoding as well.

Answer 3

I can think of four approaches:

1. A Twitter approach: You register the Client and then it calls back periodically with a GET to retrieve any notifications.

2. The Client describes how it wants to receive the notification when it makes the registration request. That way you could allow JMS for those that can handle it and fall back to email or similar for those that can't.

3. Take a URL during the registration request and POST back to each Client individually when you have a notification. Hardly Pub/Sub but the effect would be similar. Of course you'd be assuming that the Client was listening for these notifications and had implemented their Client according to your specs.

4. Buy IBM WebSphere MQ (MQSeries). Best IBM product ever. Not REST but it's great at multi-platform integration like this.

Answer 4

We have this problem and need low-latency asynchronous updates to relatively few listeners. Our two alternative solutions have been:

1. Polling: Hammer the list of resources you need with GET requests
2. Streaming event updates: Provide a monitor resource. The server keeps the connection open. As events occur, the server transmits a stream of event descriptions using multipart content-type or chunked transfer-encoding.