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 there is no guarantee that the client programs will be Java programs and hence I won't be able to use JMS for this (i.e. if every client was a Java app then we could allow the clients to subscribe to a JMS topic and listen there for notification messages).

The use case is roughly as follows:

1. A client registers itself with my server application, via a RESTful web service call, indicating that it is interested in getting a notification message anytime a specific object is updated.
2. When the object of interest is updated then my server application needs to put out a notification to all clients who are interested in being notified of this event.

As I mentioned above I know how I would do this if all clients were Java apps -- set up a topic that clients can listen to for notification messages. However I can't use that approach since it's likely that many clients will not be able to listen to a JMS topic for notification messages.

Can anyone here enlighten me as to how this problem is typically solved? What mechanism can I provide using a RESTful API?

Thanks in advance for any suggestions.

--James

Answer 1

Remember that REST is all about resources and HTTP. How would you do this with HTTP? HTTP is a request/response protocol, not a publish/subscribe protocol.

Answer 2

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 3

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.