Eli*_*ana 12 api rest esb messagebroker
我有一个系统,它使用一组丰富的CRUD端点公开REST API来管理不同的资源.REST API也由使用Ajax执行调用的前端应用程序使用.
我想让其中一些调用异步并增加可靠性.
显而易见的选择似乎是消息代理(ActiveMQ,RabbitMQ等......).
从来没有使用过消息代理,我想知道它们是否可以"放在"REST API之前,而不必重写它们.
我不想仅通过消息传递系统访问REST API:对于某些端点,呼叫必须始终是同步的,并且可靠性不太重要(主要是因为如果出现错误,用户会收到即时反馈).
完整的ESB是否可以成为此用例的更好选择？
如果我理解您的问题，您希望将 API 端点“注册”为订阅者，以便它可以接收发送到给定队列的消息。
我不认为可以配置消息代理来执行此操作。
例如，如果您想使用消息代理，您的生产者和订阅者都需要使用 JMS API。
我不知道是否可以实现一个订阅者来执行相应的 API 调用。在这种情况下，可靠性会受到影响，因为消息将在 API 调用执行之前出列。如果订阅者在 API 的同一进程中运行是有意义的，但在这种情况下，不清楚为什么应该使用 REST API 而不是库。
IMO @EligioEleuterioFontana 您对以下角色有误解：
这是两个不同的子系统，提供不同的服务。
现在，让我们根据您的要求解释它们的作用：
如果我猜对了，那么我会这样回答：
所有客户端都需要将请求推送到 REST API，因为这不仅仅是简单的 CRUD。Api 还处理安全（身份验证和授权）、缓存、甚至可能的请求限制等问题。
REST API 应该始终是客户端的前端，因为这也“隐藏”了 API 使用的子系统。用户永远不应该看到/知道您的任何子系统选择（例如，您正在使用什么数据库。您是否缓存？如果是，用什么？等）。
消息代理非常适合卸载现在请求的工作并在以后处理工作。有很多方法可以做到这一点（队列或发布/订阅等），但这里的重点是这是一个客户永远不应该看到或知道的决定。
MB 对弹性也很有用（正如您所指出的）。如果出现故障，队列中的消息将在 'x' 时间后重新尝试......等等（不，我不会提到毒队列、死信队列等）。
您可以拥有一些同步的 Api 端点。当然！然后让其他人利用一些最终的一致性（即对于那个请求，我稍后会处理它（即使在 5 秒后），然后将响应返回给客户说“谢谢！明白了！我会做的很快”）。这是您所追求的异步工作流。
API 端点需要简单、简洁并且希望非常稳定。你在幕后做的事情，希望你改变事情会隐藏起来，远离客户。这包括使用消息代理。
无论如何，我对 REST API 和消息代理的看法以及它们如何相互关联。