事件侦听器与REST调用

马丁·福勒就是这么称呼的 smart endpoints and dumb pipes .

至于哪一个更好:没有明确的“胜利者”,因为那些不是相互排斥的。它们服务于不同的语义目的(尽管可能提供相同的结果),并且可以在一个应用程序中一起使用。

唯一需要记住的是,事件模型本质上是异步的,您应该这样对待它。当然,您可以想出一些SLA来使消息传递看起来是同步的,或者在前端创建类似于同步的效果,但是仍然可以。

至于优缺点,我可以给你一些陈述,可以帮助你决定何时使用哪种技术:

• 联轴器 -比较反应式事件驱动模型和普通API,您可以说API提供了更紧密的耦合,因为您必须遵循一些预定义的接口。在这方面,信息并不那么严格,但如果需要的话,可以这样做。
• 缩放比例 -事件驱动模型的扩展要容易得多:创建更多的工人,你就完成了。然而,这种无状态性可能成为一个问题——您可能需要同一个工作者来处理特定的事件,这可能导致非常困难的排队体系结构。
• 错误处理 -在RESTAPI中实现错误处理可能和抛出适当的错误一样容易,并且可以用它来完成。但是,如果您需要重试失败的外部服务请求怎么办?应该在API后端完成还是必须在客户端完成?如果每个请求需要不同类型的重试逻辑,该怎么办?您的API可能变得过于智能,这通常是一件坏事
• 阻塞与非阻塞 -如果您的服务不符合预期的SLA,您是否有应急计划?阻塞也可能是一个问题,但至少您可以控制流和监视执行过程。
• 弹性 -如果您的API在执行过程中崩溃,您可能会丢失有价值的数据。排队可以让您等到工作人员再次出现时再排队。

这些只是亮点,这个列表并不是最终的。这两种技术在应用程序中都具有不同的复杂性。这里最好的建议是使用定性陈述(类似上面的那些),常识和亲吻来决定哪个更适合你的情况(或者两者都适合?).