如何将REST API拆分至多个项目实现？含小程序URL路由配置场景

看起来你遇到了一个典型的微服务拆分场景——把关联的REST API拆分到两个独立的项目（及对应小程序），但受限于每个小程序的URL配置限制，没法直接处理嵌套的路径。下面是几个实用的解决方案，你可以根据自己的技术栈和需求选择：

方案1：重构API路径，让资源独立 #

最直接的办法是调整产品相关API的路径，不再嵌套在客户路径下，改用查询参数关联客户。比如：

• 原客户API保持不变：/customers、/customers/{cid}（由Project1处理）
• 产品API改为独立前缀：/products、/products/{pid}，通过customerId查询参数关联客户，比如/products?customerId={cid}或者/products/{pid}?customerId={cid}（由Project2处理）

优点：

• 完全符合每个小程序的URL配置限制，Project1只需要处理/customers/*，Project2处理/products/*
• API结构更清晰，每个资源的职责独立
• 避免了跨服务的嵌套路径依赖

注意点：

• 需要在Project2的产品API中添加权限校验，确保请求中的customerId属于当前认证用户，防止越权访问
• 前端需要调整请求路径，把原来的嵌套路径改成带查询参数的形式

方案2：引入API网关做路由转发 #

如果希望保留原有的嵌套API路径（不想改动前端），可以在两个小程序前面加一层API网关，负责路径路由：

• 网关配置路由规则：
  • 所有/customers/*的请求（除了/customers/{cid}/products/*）转发到Project1
  • 所有/customers/{cid}/products/*的请求转发到Project2，同时把{cid}提取出来，作为请求头（比如X-Customer-ID）或者查询参数传递给Project2
• Project2的产品API可以通过请求头或参数获取cid，处理对应的产品逻辑

优点：

• 前端不需要任何改动，依然可以使用原有的嵌套路径
• 两个小程序的URL配置依然保持简单，Project1处理/customers/*，Project2处理自己的产品路径（网关转发过来的请求）

注意点：

• 需要额外部署和维护API网关组件，增加了系统复杂度
• 要确保网关转发时正确传递认证信息（比如token），避免Project2无法验证用户身份

方案3：让Project1作为代理转发产品请求 #

如果没法引入网关，也可以让Project1承担代理的角色：

• Project1处理/customers/*的所有请求，当收到/customers/{cid}/products/*的请求时，把请求转发到Project2的产品API，同时传递cid和认证信息
• Project2的产品API可以接收转发过来的请求，根据cid处理逻辑

优点：

• 同样不需要改动前端，保留原有嵌套路径
• 不需要额外的网关组件，利用现有Project1的能力

注意点：

• 增加了Project1的复杂度，需要处理代理逻辑、错误转发、超时等问题
• 会产生额外的网络请求（Project1 → Project2），需要考虑性能影响
• 要确保代理时正确传递请求头和认证信息，避免Project2无法识别用户

你可以根据自己的实际情况选择最合适的方案，如果团队能接受前端改动，方案1是最简洁的；如果希望保持前端体验不变，方案2或3更合适。

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