发布/订阅REST-HTTP简单协议Web服务体系结构？
我问你对“建筑”场景的看法：
我正在寻找一个最简单的发布/订阅架构，让我们在互联网上讨论两个分离的服务器，共享“稀疏”但“实时”的消息/事件。
让我解释：
-
PUBLISHER：是一个生成某种事件的服务器（ http://www.server.com ）（通过电子商务网站上的例如events == ORDERS数据）。
-
订阅者（一个或多个）：“客户”是否可以订阅以接收ORDERS事件（ http://www.client.com ）。
在现实生活中，发布者是由第三方开发的服务器（在Rails中）。 目前我可以通过简单的“轮询”策略将“订单”与其接口：每N秒我调用一次GET / new_orders。
坏！
所以我正在考虑使用REST方法更好的pub / sub架构，其中Publisher共享EVENTS资源：
-
客户订阅接收事件，向发布者提供将来要调用的“URL HOOK”（例如： http ： //www.client.com/orders ）。
-
发布者，当有新事件（==订单）时，只需将HTTP POST数据发送到客户端之前提供的客户端URL挂钩。
合理 ？ 或者我正在重新发明轮子？
顺便说一句，我用Ruby语言开发，我知道pub / sub消息系统就像Faye。 但是你怎么看待这个简单的协议（我想简单地使用Ruby / Sinatra实现客户端）？ （见图1 ）
任何建议欢迎。 非常感谢
乔治
任何时候你都可以让第三方POST到你的网络服务，这是一件好事！ 很多时候，这不是一个选项，你必须采用某种低效的轮询架构。 我不认为您的架构图有任何问题。
您可以随时使用第三方消息传递系统（Amazon SQS，RabbitMQ等），但除非您需要持久消息传递 ，否则没有太多理由这样做。
编辑：
如果您担心HTTP流量 – 特别是对您的Web服务进行的呼叫数量 – 您还可以鼓励第三方支持批量POST。 也许他们只能每5分钟向订户发送新订单作为批次的一部分。