RESTful API子路由最佳实践：独立/item/{id}路由设计是否合规

首先明确结论：你当前的设计不属于RESTful API的不良实践，两种路由设计都符合REST规范，核心差异是适用场景不同。

两种方案的优劣势对比 #

你当前使用的拆分路由方案 #

路由规则：

• 分类商品列表：/market/items/{category}
• 商品详情：/item/{id}/

优势：

• 资源标识符稳定性更高：只要商品ID是全局唯一的，该路由永远可以定位到对应商品，不会因为商品后续调整分类出现旧路由失效的问题
• 开发维护成本更低：服务端不需要额外校验分类参数和商品实际所属分类的匹配关系，也不需要处理分类变更后的路由重定向逻辑
• 适配场景更广：全局商品搜索、跨分类商品推荐等场景都可以直接复用该详情路由，不需要额外做参数适配

劣势：

• 路由语义相对较弱，无法从路由直观看出商品所属的分类层级

嵌套路由方案 #

路由规则：

• 商品详情：/market/items/{category}/{id}

优势：

• 语义清晰，符合用户对「分类-商品」层级资源的认知，从路由就可以直接识别资源的所属层级
• 方便做分类维度的权限管控、缓存策略、流量统计等附加逻辑

劣势：

• 路由稳定性差：如果商品支持调整分类，旧分类下的详情路由会直接404，需要额外开发重定向逻辑保证兼容性
• 维护成本高：服务端需要额外校验分类参数和商品属性的匹配关系，否则会出现同个商品对应多个不同分类路由都可访问的问题，破坏资源标识符的唯一性

选型建议 #

• 如果你的商品ID是全局唯一、且支持修改分类：保留你当前的设计即可，完全符合RESTful设计规范
• 如果商品分类是固定不可修改的属性，且你有分类维度的管控需求：可以选择嵌套路由方案

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