为什么大多数API网关解决方案都不支持“聚合”？

在阅读有关API Gateway的内容时，每一次出现的一件事是API Gateway是一个您应该在其中汇总多个端点的结果的地方。听起来真的很好。但是，许多流行的API网关解决方案（例如AWS API Gateway，Kongo和Netflix Zuul）不支持该功能。您需要自己修改或实施自定义过滤器。

聚合被视为不良做法吗？人们如何从多个端点返回结果？

有多种方法可以回答此问题：

端点聚合

API网关大多数情况下会聚合其他端点，而不一定会聚合结果。也就是说，它是一台服务器，可以使用其他功能（例如身份验证或路由）来镜像其他端点。

关键是集中一些服务，从外部网络隐藏实际的服务器，等等。

结果汇总

如果您真的想在网关上使用业务逻辑，将不同的文档放到另一个文档中，或者只是更改请求或响应，那么您可能正在使用Enterprise Service Bus。

聚合是否良好

这当然是有争议的，并取决于个人的意见。有人可能会争辩说，有一个原因使我们（大部分）远离SOA / ESB类型的解决方案。原因可能是因为个人职责不明确，并且倾向于在ESB端进行收集，使端点变得“笨拙”。最终导致ESB知道了一切。

“ REST”方法是不同的。它建立在“智能”端点上，知道它们的组成部分，并确保没有其他组件需要知道任何细节。这个想法本身似乎与使网关更多地了解响应有所冲突。

确实，有一些体系结构构想，例如Self-Contained Systems，就是基于该构想的，即客户所需的任何功能都应由给定的端点完全覆盖。它不应该需要与他人同步通信履行自己的职责范围内的请求。这也表明汇总结果可能适得其反。

与往常一样，这完全取决于确切的要求。