Publish / subscribe to REST-HTTP Simple Protocol web services architecture?

I ask for your judgments about the "architectural" scenario:

I would look for the simplest publish / subscribe architecture to allow talking about two decoupled servers on the Internet, sharing “sparse” but “real-time messages / events”.

Let me explain:

  • PUBLISHER: It is a server ( http://www.server.com ) that generate some kind of events (for example, the event == ORDERS data on the e-commerce website).

  • SUBSCRIBERS (one or several): "Clients" can subscribe to receive ORDERS events ( http://www.client.com ).

In real life, a publisher is a server developed (in Rails) by a third party. At the moment, I can interact with receiving “orders” with a simple “polling” strategy: every N seconds I call GET / new_orders.

BADLY!

So, I'm thinking of a better pub / sub architecture with a REST approach in which Publisher shares the EVENT sources:

  • Customer Subscribe to receive events by supplying the publisher with a “URL HOOK” ​​for future calls (for example: http://www.client.com/orders ).

  • Publisher, when there is a new event (== order), just the HTTP POST data to the client Hook URL previously provided by the client.

Make sense? Or am I reinventing the wheel?

By the way, I am developing in Ruby, and I know about messaging / sub-messaging systems like Faye. but what do you think of this simple protocol (I would like the implanted client interface to be just with Ruby / Sinatra)? (see image 1 )

Any suggestion is welcome. Many thanks

Giorgio

simple architecture proposed

+5
rest ruby web-services publish-subscribe messaging
source share
1 answer

Anytime you can get third-party POSTs for your web services, that's good! A lot of time, this is not an option, and you should resort to some kind of inefficient survey architecture. I do not think that something is wrong with your architecture diagram.

You can always use third-party messaging systems (Amazon SQS, RabbitMQ, etc.), but there is no reason for this if you do not need durable messaging .

EDIT:

If you are concerned about HTTP traffic - in particular, the number of calls made to your web service, you can also recommend a third party to support packet POSTING. Perhaps they can send new orders to subscribers every 5 minutes as part of a package.

+3
source

All Articles