无法在URI中放置会员ID时如何设计RESTful API的URI？

你的初步设计/plans/active完全符合行业常规，是该场景下的合理方案，原因如下：

• 当资源的归属方可以通过请求携带的身份凭证（你提到的请求头token）唯一确定时，不需要强制将用户标识放在URI中，反而可以避免会员ID泄露的安全风险，同时简化前端调用逻辑，不需要前端额外维护、传递会员ID参数。
• 该URI语义清晰，明确指向「当前请求方的生效支付方案」这一资源，没有歧义，符合REST API的设计原则。

如果想要进一步提升路由的可维护性，避免和全局支付方案类接口冲突，可以调整为加/me前缀的形式：/me/plans/active
这也是行业内非常通用的设计，/me前缀直接表明该路由下的所有资源都属于当前登录用户，后续扩展同类型接口时路由规则会更统一，比如：

• /me/plans：返回当前登录会员的所有可选支付方案
• /me/plans/history：返回当前登录会员的支付方案变更历史
• /me/plans/active：返回当前登录会员的生效支付方案

在ASP.NET Core中你可以通过中间件/授权过滤器解析token拿到会员ID后，直接注入到当前请求的上下文里，业务层直接从上下文取会员ID做数据过滤即可，只要做好权限校验，不会出现越权访问问题。

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