这两种路由结构各有优劣，没有绝对的「最优解」，核心得看你的业务场景和API的定位。我来拆解下两者的特点，帮你做判断：

一、绑定当前用户到/users/**/*的结构（第一种） #

优点 #

• 简洁友好：当前用户操作自己的资源时，不用每次在路径里带ID，比如改密码直接发PUT /users/password就行，前端不用额外存储或拼接用户ID，减少重复工作。
• 权限边界清晰：天然区分「个人操作」和「跨用户操作」，比如/users/preferences是自己的偏好，/admin/users/123/preferences是管理员操作他人的，路由层级一目了然，不容易混淆。
• 降低误操作风险：路径里没有用户ID参数，不会出现前端传错ID导致操作他人数据的低级错误。

缺点 #

• REST语义不够严谨：从REST「资源唯一标识」的角度看，/users/preferences其实是「当前用户的偏好」的别名，它本身不是一个独立的全局资源，资源模型的语义完整性稍弱。
• 扩展性受限：如果后续需要支持管理员代用户操作、用户切换等场景，得额外新增一套带ID的路由（比如/users/:id/preferences），会增加路由维护的复杂度，两套路由逻辑容易不一致。

二、带ID的绝对路径结构（第二种） #

优点 #

• 符合REST规范：每个资源都有唯一的绝对路径，比如/users/123/preferences明确指向用户123的偏好，语义清晰，完全贴合REST「一切皆资源」的设计理念。
• 灵活性拉满：同一个路由模式可以兼容「当前用户操作」和「跨用户操作」——你可以把me作为当前用户的别名，比如/users/me/preferences等价于当前用户的偏好，管理员操作他人时直接用真实ID即可，不用维护两套路由。
• 可扩展性强：后续新增协作、共享类功能时，路由结构不用大改，比如要获取用户123共享给我的文档，直接用/users/123/shared-documents/:id就能延续现有模式。

缺点 #

• 前端稍显繁琐：即使使用me作为别名，路径也比第一种多了一个段（/users/me/xxx vs /users/xxx），需要前端统一处理这个别名逻辑。
• 权限校验要求更高：必须在后端严格校验路径中的ID和当前登录用户的ID是否匹配（除非是拥有权限的管理员），否则容易出现越权访问的安全问题。

综合建议 #

• 如果你的API90%以上都是当前用户的个人操作，很少涉及跨用户或管理员操作，第一种结构更简洁易用，开发效率更高。
• 如果你的API需要频繁支持跨用户协作、后台管理等场景，第二种结构更规范灵活，搭配/users/me别名可以兼顾简洁性和规范性，是更长远的选择。

另外补充一个细节：第一种结构里的/documents/:id要注意语义歧义——这个文档是属于当前用户的，还是全局的？如果是前者，建议调整为/users/documents/:id，避免后续出现资源归属不清晰的问题。

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