同一资源是否需设置多条API路由？权限场景下的路由设计困惑

你的这种多路由设计完全合理，核心原因是两个路由对应的业务语义和访问场景本质不同：

• /api/project/1/items 代表「某个特定项目下的子资源Items」，符合RESTful嵌套资源的设计逻辑，适配项目经理仅能管控自身负责项目的权限场景；
• /api/items 代表「全局所有Items资源」，对应管理员的全量访问需求，语义清晰直接。

如果想优化现有设计，或者减少路由数量，可以参考以下替代方案：

方案1：统一路由 + 权限驱动的过滤逻辑 #

保留顶级路由 /api/items，通过用户身份自动过滤数据：

• 管理员访问时，无需额外参数，直接返回全量Items；
• 项目经理访问时，自动注入其负责的项目ID作为过滤条件（无需前端传参），返回对应项目的Items；
• 若前端主动传projectId参数，需在校验环节判断该项目是否属于当前项目经理负责，防止越权。

这种方案的优势是减少路由数量，但要注意：必须在权限校验层严格控制数据范围，避免出现项目经理通过篡改参数访问其他项目数据的情况。

方案2：复用业务逻辑层，减少代码冗余 #

如果坚持保留两条路由，建议将Items的查询、修改等核心业务逻辑抽离到独立的服务层（比如ItemService），两条路由仅做参数解析和权限校验：

• 对于 /api/project/:projectId/items：解析projectId，校验当前用户是否为该项目的项目经理，然后调用服务层的getItemsByProjectId(projectId)方法；
• 对于 /api/items：校验用户是否为管理员，调用服务层的getAllItems()或modifyItems()方法。

这样既能保留语义清晰的路由设计，又能避免重复编写业务代码，降低维护成本。

关键注意事项 #

• 权限校验必须前置：不管用哪种方案，都要在路由处理的最开始完成身份和权限验证，避免无效的业务逻辑执行；
• 路由语义保持一致：避免出现类似/api/items和/api/project-items这种语义混淆的命名；
• 明确文档说明：在API文档中清晰标注每条路由的权限要求、参数规则和返回范围，方便前后端开发协同。

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