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.

Answer 1

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 State and Statelessness at page 217 of RESTful Web Services for the difference between application and resource state)

Answer 2

Just a fast check on the REST constraints:

• client-server architecture
• stateless
• cache
• uniform interface
  • identification of resource
  • manipulation of resource through representations
  • self-desriptive messages
  • hypermedia of the engine of application state
• layered system
• code on demand (optional)

From the Fielding dissertation:

The client-server style is the most frequently encountered of the architectural styles for network-based applications. A server component, offering a set of services, listens for requests upon those services. A client component, desiring that a service be performed, sends a request to the server via a connector. The server either rejects or performs the request and sends a response back to the client.

Btw. an event based system would probably violate most of the constraints. It is hard to define things like hypermedia the engine of application state without clients (since the other name of application state is client state) and hyperlinks (since they are meaningless by pub/sub), and so on...

Anyways it is an interesting question how to design an event based system somewhat similar to REST. I think you should publish self-descriptive messages containing RDF, but that's just a tip. Polling can be a viable solution, but if I were you I would not try to force REST on an event based system...

update 2016.05.15.

As far as I understand the client - server architecture - Fielding describes here and here in his dissertation - uses always REQ/REP communication. The client sends the request and the REST service responds. If you want to have something like PUB/SUB without the violation of the client - server constraint, the only way to do that is the usage of polling. If you don't want to use polling, then ofc. you can use a REST service and a websocket service together, it is not forbidden...

Answer 3

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 (you can also look into something like websockets, if you're dealing with a browser). 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 4

Webhooks are the answer to this problem. They allow events without violating the REST principles.

Answer 5

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.