URL Scheme设计：资源ID应放路径还是查询参数？各方案适用场景

方案1：/book/{user_id} #

• 适用场景：仅适合调用方完全可控的内部临时接口、性能优先的极简内部服务接口，完全不适合对外开放的公开API。
• 设计原因：这个方案的路径长度最短，开发时不需要处理多级路径映射，也不需要额外解析查询参数，网关路由规则配置最简单，拼接和调用的成本最低。但它的语义歧义非常明显——按常规URL设计习惯，/book后面的路径参数一般是书籍ID，直接放用户ID很容易让不了解内部逻辑的调用方传参错误，所以只能在内部小范围使用，不能对外暴露。

方案2：/user/{user_id}/books #

• 适用场景：适合遵循RESTful规范的对外开放API，尤其是业务上明确「书籍从属于用户」、后续还需要围绕用户和书籍的关联关系做扩展操作的场景。
• 设计原因：这是标准的RESTful嵌套资源设计，语义完全自解释，任何人看到路径都能直接理解这是在访问「指定ID用户名下的书籍集合」，完全符合「先定位父资源（用户），再访问父资源下的子资源集合（书籍）」的资源层级逻辑。后续扩展接口也非常顺畅，比如要查询/修改/删除用户名下的某一本书，直接延伸路径为/user/{user_id}/books/{book_id}即可，路由规则清晰，不管是内部开发维护还是外部调用方对接，理解成本都极低，是从属类资源接口的首选规范设计。

方案3：/book?user_id={user_id} #

• 适用场景：适合书籍作为系统顶级核心资源、查询筛选维度灵活多变的通用列表/搜索接口，比如支持多条件组合筛选的书籍广场、用户书架混合查询类场景。
• 设计原因：这个设计把「所属用户」作为书籍资源的一个普通筛选条件放在Query参数里，和顶级资源路径/book完全解耦。后续不管加多少种筛选维度（比如书籍分类、出版时间、标签、评分、上架状态等），都不需要修改基础路径，只需要追加对应的查询参数即可，比如要查ID为1001的用户名下分类为计算机、2022年后出版的书，直接拼接为/book?user_id=1001&category=tech&publish_after=2022就能实现，接口兼容性极强，不需要为不同的筛选组合单独开发不同路径的接口，非常适合查询条件灵活的资源检索场景。

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