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

Question

I'm asking your sugegstions about an "architectural" scenario:

I'd looking for a simplest publish/subscribe architecture to let talk two decoupled servers over on internet, sharing "sparse" but "real-time" messages/events.

Let me explain:

• The PUBLISHER: Is a server (http://www.server.com) that generate some sort of events (by example events==ORDERS data on a e-commerce website).

• SUBSCRIBERS (one or more): Are "clients" that can subscribe to receive ORDERS events (http://www.client.com).

In real life case, the publisher is a server developed (in Rails) by a third party. At the moment I can interface it getting "orders" with a plain "polling" strategy: every N seconds I call a GET /new_orders.

BAD!

So I'm thinking about a bit better pub/sub architecture with a REST approach where Publisher share the EVENTS recources:

• The client Subscribe to receive events, supplying to the Publisher a "URL HOOK" to be call in future (by example: http://www.client.com/orders).

• The Publisher, when there is a new event (== order) simply HTTP POST data to client URL Hook previously supplyied by Client.

Make sense ? Or I'm reinventing the wheel ?

BTW, I develop in Ruby language and, I'm aware of pub/sub messaging systems as Faye. but what do you think about this simple protocol (I'd like implment client-side simply with Ruby/Sinatra) ? (see image 1)

Any suggestion welcome. Thanks a lot

Giorgio

Answer 1

Any time you can get a third-party to POST to your web services, it's a good thing! A lot of the time, this isn't an option and you must resort to some kind of inefficient polling architecture. I don't think there's anything wrong with your architecture diagram.

You can always use third-party messaging systems (Amazon SQS, RabbitMQ, etc.) but there's not much reason to do that unless you need durable messaging.

EDIT:

If you're concerned about HTTP traffic--specifically, the number of calls being made to your web service--you could also encourage the third-party to support batch POSTing. Perhaps they can only send subscribers new orders every 5 minutes as part of a batch.