好的..所以我已经开始研究 MQ 及其用途/用例等...我现有的应用程序（使用 JSP 等制作的 Web）使用 RestFUL 接口与远程服务器通信并从服务器发布/接收数据。
我们经常要处理远程服务器的连接问题。同步问题总是存在的。
从我们端发送的消息。但是远程服务器出现故障。或相反亦然。
我遇到了 MQ 的东西，发现它在发送和接收来自远程服务器的消息时是可靠的。
但同样，使用 REST 我认为对 MQ 的整个需求似乎有点模糊。我基本上是在寻找 MQ 和 RestFUL 之间的一些差异。
我在其他博客文章中读到，随着 RestFUL 领域研究的增加，MQ 将慢慢放慢步伐。
我对 MQ 不太了解，所以不会发表任何评论，但使用 RestFUL 肯定很有趣。
如果有人提供使用 RestFUL 和 MQ 之间的差异，将不胜感激。
最大的区别之一是 REST 意味着同步处理，而 MQ 通常是异步的。正如您已经提到的，MQ 是一种分离生产者和消费者的方法，这样他们就不必同时在线，但系统仍然可以作为一个整体运行。如果您的用例意味着低延迟响应（例如使用浏览器的用户），您需要同步语义，在这种情况下 MQ 只是一个不同的协议。如果延迟不是问题，或者只有一个方向的消息传递，MQ 可能是一个非常可行的替代方案。MQ 免费提供的一件事是消费者端的负载平衡（和某种级别的 HA）。
REST 在客户端/服务器兼容性方面更加灵活。您几乎可以在每个平台上运行 REST 客户端，而 MQ 并非如此。我想，这就是为什么有些人声称 MQ 已经过时的原因。因此，MQ 不适用于公共 API。但是，对于两个服务器系统之间的通信，MQ 仍然是一个非常好的选择。REST 的一个独特功能是它允许您完全模仿资源（超媒体）的 WEB 行为，即一个资源包含对另一个资源的引用，依此类推。MQ 无法提供类似的东西。
性能可能是另一个问题。我无法给出任何确切的数字，但 MQ 往往具有更大的吞吐量。
在极少数情况下，由于安全要求，客户端无法直接连接到服务器。在这种情况下，MQ 几乎是向服务器发送数据的唯一方法。
总而言之，根据经验，我会使用 REST
MQ
REST 和 MQ 都支持远程系统（和本地）之间的通信。
在 REST 通信中，消费者和 REST 服务提供者应该正在运行以使通信成功。这是一个点对点的通信。
在 MQ 模型中，生产者和消费者不需要同时运行。生产者和消费者不直接交互。消息代理负责处理消息、持久化消息等。支持点对点和发布-订阅模型。在发布订阅模型中，一条消息可以被多个消费者消费。
这些只是区分它们的一些基本点。SO上有足够多的帖子讨论REST和MQ。
两者都是抽象，但在不同的层次上你的应用程序可以提供 RESTful API，但在底层它会利用各种组件，其中包括消息队列。
简短而肮脏：RESTful 声明了如何构建应用程序或组件的最佳实践，MQ 服务于组件之间的消息传递。
您可能对 RPC 感到困惑，但在 Web 上下文中，它与 MQ 不同。