REST API和消息传递

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

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

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

从来没有使用过消息代理，我想知道它们是否可以“放在”REST API之前，而不必重写它们。

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

完整的ESB是否可以成为此用例的更好选择？

4
投票

如果我理解您的问题，您希望将API端点“注册”为订阅者，以便它可以接收发送到给定队列的消息。

我不认为可以配置消息代理来执行此操作。

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

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

3
投票

IMO @EligioEleuterioFontana您对以下角色有误解：

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

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

如果我已经做到了，那么我会回答：

所有客户端都需要将请求推送到REST API，因为这不仅仅是简单的CRUD。 Api还处理安全（身份验证和授权），缓存，甚至可能请求限制等问题。
REST API应该始终是客户端的前端，因为这也“隐藏”了API使用的子系统。用户永远不应该看到/了解您的任何子系统选择（例如，您正在使用什么数据库。您是否正在缓存？如果是，请使用什么？等等）。
Message Brokers非常适合卸载现在请求的工作并稍后处理工作。有很多方法可以完成（队列或发布/订阅等），但这里的重点是这是客户永远不会看到或知道的决定。
MB也非常适合弹性（如您所述）。如果出现故障，队列上的消息将在'x'时间后重新尝试...等等（不，我不会提到毒药队列，死信队列等）。

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

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

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

1
投票