21

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?
Assaf Lavie
  • 73,079
  • 34
  • 148
  • 203
  • Instead of communicating via http interfaces, both can use common pub-sub channel. Let's say, the publisher service may produce data on a kafka topic, while a consumer can subscribe to this topic and consume the data. This is good if both services and kafka cluster is hosted in a single network and latency is not the issue. – Manojkumar Khotele Mar 26 '19 at 19:17

5 Answers5

18

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)

ritesh
  • 907
  • 3
  • 11
  • 31
Colin Jack
  • 756
  • 4
  • 8
  • Hi Colin, Thanks for the link. It was very helpful. You are right, having subcriptions as resources will not break the REST constraints. Thanks again, Suresh –  Feb 27 '09 at 09:46
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 (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.

Community
  • 1
  • 1
M. Elkstein
  • 1,007
  • 2
  • 10
  • 16
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.

Assaf Lavie
  • 73,079
  • 34
  • 148
  • 203
0

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...

Community
  • 1
  • 1
inf3rno
  • 24,976
  • 11
  • 115
  • 197
  • Is it really violating the client-server architecture? If client A provides a callback to server B to be notified of changes then B becomes a client of A and A will be a server for B. Is there a requirement that a component can't be both client and server? – user3285954 May 13 '16 at 08:28
  • @user3285954 http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_2 It does not make sense to me, but I am not certain. :-) – inf3rno May 13 '16 at 13:26
  • @user3285954 Let's examine this from another aspect. In theory it is possible to use circular dependency. So you have 2 REST services which depend on each other. This would clearly violate the layered system constraint: "A layered system is organized **hierarchically**, each layer providing services to the layer above it and using services of the layer below it [53]." – inf3rno May 13 '16 at 13:47
  • @user3285954 You can read more about the client - server constraint here: http://byterot.blogspot.hu/2012/07/what-does-rests-client-server-mean-now.html – inf3rno May 13 '16 at 13:53
  • I wouldn't call layers and services the same. Sometimes they are the same but sometimes a service is just a service, especially if it's a 3rd party service. Webhooks got quite mature by now, have a look because they handle events in service based (even REST) environments. I would also note that very few services called REST or RESTful are actually complying with the REST principles. People nowadays call everything using json over HTTP a REST service. – user3285954 May 14 '16 at 22:11
  • @user3285954 Actually they call everything RESTful as well, that's why we use "Hypermedia APIs" nowadays, because they never heard of that. :-) No, they are not the same, services are on layers. But layers are hierarchical, so services must be hierarchical as well. At least I think so. I'll check your webhooks, maybe I learn a new perspective. If you have time to read, this is a great PDF about REST + RDF: http://www.markus-lanthaler.com/research/third-generation-web-apis-bridging-the-gap-between-rest-and-linked-data.pdf Page 20 discusses this REST word misusage topic. – inf3rno May 15 '16 at 08:43
0

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

user3285954
  • 4,499
  • 2
  • 27
  • 19