如何在API网关中组合多个API调用？项目实践困惑咨询

这确实是API网关设计中很容易踩的坑，我当初搭建微服务网关的时候也纠结过这个点，给你梳理下思路：

先搞懂：为什么不建议暴露复合API？ #

你最初想创建的那种“调用多个API的复合API”，本质上是把聚合逻辑封装成了一个新的服务API再通过网关暴露，这种模式的问题在于：

• 耦合性太高：前端直接依赖这个复合API的结构，后续如果后端服务接口调整，你得同时修改复合API和前端，灵活性很差
• 重复造轮子：API网关本身就具备请求路由、聚合、编排的能力，没必要额外再套一层复合API，反而增加了架构复杂度

网关内组合 ≠ 暴露领域逻辑 #

核心要区分数据聚合逻辑和核心领域逻辑：

• 网关该做的：只负责无业务规则的数据拼接/聚合，比如前端需要展示用户基本信息+最近5条订单，网关可以并行调用用户服务和订单服务，把两个接口的返回结果合并成一个响应返回给前端，这个过程完全不涉及业务判断
• 不该让网关做的：核心领域逻辑（比如判断用户是否有购买权限、计算订单折扣金额、校验用户身份合法性这些），这些必须留在后端的领域服务里处理，绝对不能放到网关中

举个实际的例子：

前端需要一个接口返回用户详情+已购课程列表
正确做法：网关收到请求后，分别调用/user/{id}和/orders/user/{id}?type=course，把两个接口的userInfo和courseList字段合并成一个JSON返回
错误做法：在网关里判断用户是否是VIP，然后决定是否返回全部课程列表——这部分逻辑属于领域服务的职责，网关碰了就是越界

实践中的平衡技巧 #

如果你的聚合需求涉及一些和前端适配相关的轻量逻辑（比如字段重命名、过滤非必要数据），可以考虑引入**BFF（Backend for Frontend）**模式：

• BFF作为网关和后端服务之间的中间层，专门为前端定制接口，处理和前端相关的聚合、适配逻辑
• 网关只负责流量转发、鉴权、限流这些通用能力，BFF处理和前端场景绑定的逻辑，这样既避免了网关越界处理领域逻辑，又满足了前端的定制化需求

总结 #

网关内做组合操作，只要守住“只处理数据聚合，不碰核心业务规则”的边界，就完全不会暴露领域逻辑。反而比暴露复合API的模式更灵活，也更符合API网关的职责定位。

内容的提问来源于stack exchange，提问作者Leonz