Event Based interaction style in REST

Question

I am currently struggling with a design issue involving REST. The application I am designing has a requirement to send out events and also support pub/sub style of interaction. I am unable to come up with a design to provide these interaction style without breaking the REST’s “Stateless interaction” constraint. I am not against polling as some people seem to be (polling sucks) , but my application demands a event based and pub/sub style of interaction (polling is not an option for me). So, my question is:

1. Can I design a RESTful application that supports event based and pub/sub interactions without breaking the REST contraint?
2. Is REST style suitable for this kind of interaction style?

Answer 1

I don't see a reason why RESTful interfaces should not support events.

It will have to be done through polling, mind you; and that would be true even if you were to use SOAP instead.

While your web servers should definitely remain stateless, you probably do have a DB somewhere on the back end. You can use this DB to handle subscriptions to events by adding a subscription table.

Answer 2

I assume you mean the server should notify the clients about events. I don't see how the specific technology matters here: you will face the same problems, and have to pick a solution from the same pool, regardless of using REST, SOAP-based web services, or any other alternative.

The basic question is, can your server initiate connections? Complementing this, can the clients listen to a port? If so, the client registers (sub), and the server notifies of events (pub). Both the registration operation and the notification events can be RESTful.

You need both server-initiated connections and listening clients. If either is not an option (e.g., because the client is a web browser), you will have to make do with polling. Design your polling carefully: the server response to the polling event should indicate a minimum delay before the client may poll again. The initial implementation of the server can return a constant for this delay value, but later on (assuming the clients are well-behaved) this will allow you to control the load on the server, differentiate between critical and less-critical clients, and so on.

And of course, the polling can be RESTful.

Answer 3

Here is a discussion on the topic by Roy.

Answer 4

Hi Assaf,

Thanks for you response. I agree that the state could be maintained in a DB or even as resource on the server side. However, this makes the server to hold client contextual information. For example, assume few clients evince interest and subscribe by sending POST requests. This can create three resources like /app/user@host:port/subscribe for each client. A server process can look at these resource and send out events to users by looking at the host and port information. In this case, I can handle the situations like the client exiting without unsubscribing by running a seperate watchdog to timeout these resources or the server can send AYA signals Both of these approaches will work but my question is will this not break the REST constraint that the server should not maintain any state related to the client?

Answer 5

I'd recommend the Distributed Observer Pattern by Duncan Cragg as a good read (bit difficult to grok but worth the effort).

As others have indicated its likely you'll need to use polling but as you rightly say subscribers could register their own interest (POST to create subscription). If you view the subscription as its own resource, a contract between the publisher and subscriber, then I wouldn't view it as a breaking REST constraints (see page 217 of RESTful Web Services for the difference between application and resource state)