RESTful 与 MQ。除保证交付外的差异和其他主要功能

Question

好的..所以我开始研究 MQ 及其目的/用例等...我现有的应用程序(使用 JSP 等制作的 Web 等)使用 RestFUL 接口(interface)与远程服务器通信并从服务器发送/接收数据。

我们经常需要处理远程服务器的连接问题。同步问题始终存在..

消息从我们这边发送。但是远程服务器出现故障。或相反亦然。

我遇到了 MQ 的东西，发现它在从远程服务器传递和接收消息时是可靠的。

但是，使用 REST，我认为对 MQ 的整个需求似乎有点模糊。我基本上是在寻找 MQ 和 RestFUL 之间的一些差异..

我在其他博客文章中读到，随着 RestFUL 领域研究的增加，MQ 将慢慢放慢步伐。

我对 MQ 不太了解，所以不会发表任何评论，但使用 RestFUL 肯定很有趣。

如果有人提供使用 RestFUL 和 MQ 之间的差异，我将不胜感激。

Answer 1

最大的区别之一是 REST 意味着同步处理，而 MQ 通常是异步的。正如您已经提到的，MQ 是一种将生产者和消费者解耦的方法，这样他们不必同时在线，但系统仍然可以作为一个整体运行。如果您的用例意味着低延迟响应(例如使用浏览器的用户)，您需要同步语义，在这种情况下 MQ 只是一个不同的协议(protocol)。如果延迟不是问题，或者消息传递仅在一个方向上进行，那么 MQ 可能是一种非常可行的替代方案。 MQ 免费提供的一件事是消费者端的负载平衡(以及某种级别的 HA)。

REST 在客户端/服务器兼容性方面更加灵活。您几乎可以在每个平台上运行 REST 客户端，但 MQ 则不然。我想，这就是为什么有些人声称 MQ 已经过时的原因。因此，MQ 不适合公共(public) API。然而，对于两个服务器系统之间的通信，MQ 仍然是一个非常好的选择。REST 的一个独特功能是它允许您完全模仿资源(超媒体)的 WEB 行为，即一个资源包含对另一个资源的引用，依此类推。 MQ 无法提供类似的东西。

性能可能是另一个问题。我无法给出任何确切的数字，但 MQ 往往具有更大的吞吐量。

在极少数情况下，由于安全要求，客户端无法直接连接到服务器。在这种情况下，MQ 几乎是向服务器发送数据的唯一方法。

总而言之，根据经验，我会使用 REST

• 对于公共(public) API 或
• 需要同步处理的地方

MQ

• 当仅涉及有限数量的服务器端系统时
• 异步处理是可以接受的或者
• REST 性能不够