REST API和消息传递

Question

我有一个系统，它使用一组丰富的CRUD端点公开REST API来管理不同的资源。 REST API也由使用Ajax执行调用的前端应用程序使用。

我想让其中一些调用异步并增加可靠性。

明显的选择似乎是消息代理（ActiveMQ，RabbitMQ等......）。

以前从未使用过消息代理，我想知道他们是否可以＆＃34;放在＆＃34;之前REST API，无需重写它们。

我不想仅通过消息传递系统访问REST API：对于某些端点，呼叫必须始终是同步的，并且可靠性不太重要（主要是因为如果出现错误，用户会收到即时反馈）。 / p>

对于此用例，完整的ESB是否会更好？

Answer 1

如果我理解你的问题，你想＆＃34;注册＆＃34; API端点作为订户，以便它可以接收发送到给定队列的消息。

我认为不能将消息代理配置为执行此操作。

例如，如果要使用消息代理，则生产者和订阅者都需要使用JMS API。

我不知道解决方案是否可以实现将执行相应API调用的订户。在这种情况下，可靠性受到影响，因为消息将在执行API调用之前出列。如果订阅者在API的相同进程中运行，则有意义，但在这种情况下，不清楚为什么要使用REST API而不是库。

Answer 2

IMO @EligioEleuterioFontana您对角色的误解：

• RESTful Api
• 消息经纪人

这是两个不同的子系统，提供不同的服务。

现在，让我们根据您的要求解释他们的角色：

• 您有客户（桌面浏览器，手机浏览器或应用）需要将数据传输/推送到您的系统。 （提及REST API的假设）。
• 客户端的请求使用HTTP / HTTPS（这是您要求的REST API部分）。
• 任何推送的数据，您希望使其更具响应性，更快速，更可靠。

如果我说得对，那我就回答：

• 所有客户端都需要将请求推送到REST API，因为这不仅仅是简单的CRUD。 Api还处理安全（身份验证和授权），缓存，甚至请求限制等事情。

• REST API应该始终是客户端的前端，因为这也“隐藏”了API使用的子系统。用户永远不应该看到/知道您的任何子系统选择（例如，您正在使用什么数据库。您是否正在缓存？如果是，请使用什么？等等。）

• Message Brokers非常适合卸载 now 所要求的工作并稍后处理工作。有很多方法可以做到这一点（队列或发布/订阅等），但这里的重点是这是客户永远不会看到或知道的决定。

• MB也非常适合弹性（正如您所说）。如果出现故障，队列上的消息将在'x'时间后重新尝试...等等（不，我不会提到毒药队列，死信队列等）。

您可以让Api的某些端点同步。当然！然后让其他人利用一些最终的一致性（即对于那个请求，我将在稍后处理它（即使后来在5秒之后）并且只是将响应返回给客户说“谢谢！得到它！我会做的很快“）......这是你所追求的异步工作流程。

Api端点需要简单，简洁，并且希望非常稳定。当你改变事物时，你在幕后做的事情将被隐藏在远离客户的地方。这包括使用消息代理。

无论如何，我对我如何看待REST Api和Message Brokers以及它们如何相互关联有所了解。

Answer 3

可能值得研究Google Cloud子/ pub？ - https://cloud.google.com/pubsub/docs/overview