REST还是多层异构系统中的消息队列？

我正在为三层系统设计REST API，例如：Client application-> Front-end API cloud server-> user's home API server (Home)。

Home是家用设备，应该Front-end通过Websocket或长时间轮询来保持连接（这是我们违反REST的第一个地方，以后还会更糟）。Front-end大多数情况下会将Client请求传送到Home连接并处理一些呼叫本身。有时会Home向发送通知Client。

Front-end并Home具有基本相同的API；Client可能是Home通过LAN直接连接。在这种情况下，Home需要Client在Front-end自身上注册一些操作。

该系统中REST的优点是：

• REST是人类可读的；
• REST具有明确定义的动词（如CRUD），名词和响应代码到协议对象的映射。
• 它可以通过HTTP运行并传递所有可能的代理。

REST的反对意见是：

• 我们不仅需要一种请求-响应通信方式，还需要一种发布-订阅方式。
• HTTP错误代码可能不足以处理三层通信错误。Front-end可能返回202 Accepted异步调用只是为了发现必要的Home连接断开了，应该已经连接了503;
• Home需要向发送邮件Client。Client将必须进行轮询Front-end或维护连接。

我们正在考虑通过Websocket上的WAMP / 高速公路来获得发布/订阅功能，这让我惊讶的是它已经看起来像消息队列。

是否值得评估一种消息队列作为传输方式？

看起来像消息队列相反是：

• 我需要在消息级别上自己定义CRUD动词和错误代码。
• 我读到一些有关“较高的维护成本”的信息，但这意味着什么？

这些考虑有多严重？

如果具有连接性，请使用消息队列-尽管您必须定义自己的协议（这很难完成任务！）才能发送特定结构和格式的消息。

维护方面的问题是，通常客户端和服务器是分别构建的，因此您需要注意使两端使用相同的消息定义，但是如果您的组织不够，请使用与REST中使用的XML相同的XML。服务。

如果您在Internet上存在连接问题，仅使用端口80和http以及“单向”通信，则REST风格的系统可能是最好的。发送和轮询，或获取用于回调数据的websocket，但通常将您的系统设计为客户端/服务器。如果您有能力获得连接性，那么消息传递系统就很棒。

我将使用ZeroMQ作为消息传递系统，它的可配置性足以在各种情况下（包括容错情况）扭曲。我不确定它是否可以通过http工作。

看起来高速公路似乎很适合您的工作。还有其他可用工具。签出Windows Azure Service Bus（它具有Java，.NET，PHP，Python，NodeJS和Ruby的客户端框架）。

内置的休息消息很有用。您会发现您的应用程序将超出基本的CRUD操作。例如，如果您的应用程序是银行系统。代替

更新帐户54321余额=余额-20.00更新帐户98765余额=余额+ 20.00

您可能想要一条消息，例如

将20.00从帐户54321转到帐户98765

最好是现在而不是以后发现使用REST的障碍。查看Greg Young的Event Centric，它讨论了如何为应用程序中的消息传递创建更丰富的模型。