3

My team is tasked with creating a publish/subscribe system for incoming REST messages. 99% of the time, this system will be used for notifications between different processes on the same cpu, but we will need to support notification over the network as well.

We are considering a REST based model, where a client subscribes with a POST like:

curl https://brokeripaddress/REST/function/path/subscribe -H 'Content-Type: application/json' -d '{"subscription-ip-address":"192.168.1.1", "subscription-method-filter":"*"}' -X POST

Then, when our REST service receives any call to /REST/function/path, we would clone that request, sending it to the specified subscription ip address.

Does anyone have experience with similar patterns? Is this a reasonable way to implement publish/subscribe, or are there obvious pitfalls we are missing?

Improve this question
1
  • 4
    This will only work if the subscriber is a server that listens on that IP address. This will not work if the subscriber is behind a firewall or NAT. Also, just using the IP address for identification makes it impossible to have multiple communicating processes on the same system unless that system has multiple IP addresses, so consider allowing a port to be specified. IP addresses might change, can your subscription be limited to some duration? In most cases, a subscriber-initiated permanent TCP connection is vastly superior since it solves most of these issues.
    – amon
    Commented Feb 26, 2016 at 16:37

2 Answers 2

Reset to default
2

Have a look at WebHooks for an approach example :

A web application implementing WebHooks will POST a message to a URL when certain things happen.

Improve this answer
2

First of all, you may find ready-made pub/sub solution such as AMQP or STOMP better suited to your needs than to develop you own.

But if you need to rely on HTTP transport between clients and broker and don't want/need to introduce complex solution, I would prefer subscribing via long standing GET requests to defined REST endpoint. So pulling messages instead of being pushed from broker.

  • Client send GET request with subscription attributes embedded as query parameters to endpoint, waits for response.
  • When any message matches, it's immediately send back to client as usual HTTP response.
  • When the queue is empty, request waits until anything matching arrives or timeout occurs.

You can improve protocol with batched responses, so more messages are returned in one batch if matching.

You should implement some kind of message sequence number unique to endpoint, so client could request any messages newer than last received. And it's client which is responsible to retain history and state of subscription.

If you implement persistence you can replay any subscription message sequence, i.e. if you need to do some forensic debugging.

The publishing part is still performed via POST request to the same REST endpoint. Or you can embed endpoint into publishing application and skip broker overhead completely.

If implemented properly you should not loose any messages in case of disconnected / failing subscriber, which could happen if you push messages from broker to subscribers.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.