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

Question

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

Home是一种家庭设备，应该通过Websocket或长时间投票来维护与Front-end的连接(这是我们破坏REST的第一个地方。情况会变得更糟)。Front-end主要将Client请求导入到Home连接，并自行处理一些调用。有时Home会向Client发送通知。

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

在这个系统中休息的好处是：

• REST是人类可读的；
• REST有一个定义良好的动词(如CRUD)、名词和响应代码到协议对象的映射；
• 它在HTTP上工作，并传递所有可能的代理；

其余部分如下：

• 我们不仅需要一种请求-响应的通信方式，而且还需要一种发布-订阅；
• HTTP错误代码可能不足以处理三层通信错误；Front-end可能会将202 Accepted返回到某个异步调用，结果发现必要的Home连接中断了，并且应该有503；
• Home需要向Client发送消息。Client将不得不轮询Front-end或维护连接。

我们正在考虑Websocket上的湿法/高速公路来获得发布/订阅功能，但我突然发现它看起来已经像一个消息队列了。

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

类似于消息队列控制的内容如下：

• 我需要在消息级别上自己定义CRUD谓词和错误代码。
• 我读过一些关于“更高的维护成本”的文章，但这意味着什么呢？

这些考虑有多严重？

Answer 1

如果您有连接性，可以使用消息队列--尽管您必须定义自己的协议(这不是一项困难的任务！)发送具有特定结构和格式的消息。

维护的问题是，客户端和服务器通常是分开构建的，因此需要小心使用相同的消息定义，但是如果组织不够，只需使用REST服务中使用的相同的XML即可。

如果您在互联网上有连接问题，端口80和http和‘单向’通信，那么REST风格的系统可能是最好的。发送和轮询，或获得一个websocket进行回调数据，但通常架构您的系统是客户机/服务器。如果您有能力获得连接，那么消息传递系统是很棒的。

我将使用ZeroMQ来实现消息传递系统，它的可配置性足以适应各种情况，包括容错场景。不过，我不确定它是不是在http上工作。

Answer 2

它看起来很符合你想要做的事情。还有其他可用的工具。查看Windows服务总线 (它有用于Java、.NET、PHP、Python、NodeJS和Ruby的客户端框架)。

虽然内置的rest消息很有用。您会发现您的应用程序将超过基本的CRUD操作。例如，如果您的应用程序是银行系统。而不是

更新Acct 54321余额=余额- 20.00更新Acct 98765余额=余额+ 20.00

你可能会想要一条信息

20:00从帐户54321转至帐户98765

最好现在就休息，而不是以后才能发现这个障碍。查看Greg的以事件为中心，它讨论了如何在应用程序中创建更丰富的消息传递模型。