※ 引述《chan15 (ChaN)》之铭言：
: 各位好，我正在设计公司的 RESTful api，遇到一个身份判定的问题有点卡住，想请教一下各位
: 假设我今天要拿到一个 team 里面我这个 user 的 profile，该怎么下比较好
: 1. teams/{team_id}/users/profile
: 2. teams/{team_id}/users/me/profile
: 3. teams/{team_id}/users/{user_id}/profile
: 会有这个问题是因为，一般 RESTful 都是表定是 me 了，登入后用在 header 的 token 拿取属于你的资料
: 这个定义的情况下 1 感觉是最接近的，但 users 下没有指定对象又感觉很怪，毕竟 users 是复数
: 假设 2 成立，那我 teams 想要一支 api 也透过 user_id 找其他人 profile 的话 3 跟 2 route 会打架
: 3 如果带上自己 user_id 可以解决全部问题，但又失去了直接比对 jwt token 的便利性
: for me: teams/{team_id}/me/profile
: for someone: teams/{team_id}/users/{user_id}/profile
: 如果上述成立，另一个模组是 users，专门处理 user 的内容，以忘记密码举例
: for me: users/me/forgot-password
: for someone: users/{user_id}/forgot-password
: 这 route 又打架了 XD，不确定表达的好不好，目前就是卡在该怎么在如何在 url 上可以明确看出这只 api
: 对到的是你或者是某个指定对象，route 不冲突但也可以兼顾直接拿 jwt token 来用，谢谢
在 teams A 的 users A 和 teams B 的 users A 会是不同的 user 吗？
如果不是的话要把 teams 前缀拿掉。
以目前设计到一半的 PTT API 为例， boards A 的 articles A 和 boards B 的
articles A 会是不同文章，因此要分开。
然后 me 的问题，我不建议使用 users/me 这样的做法，假如有人的 ID 是 me 会很衰
相较之下我会建议你直接用 /me/forget-password
也就是说 /me 来代表 /users/{{current_user_id}} 这样
然后推文有提到 302 我认为这也是好的作法，或是 301 也行，不过在进行Redirect的
时候务必要确定 Proxy Cache 会同时检查 Authorization ，否则有可能会看到别人的
资料。
顺带一提，我觉得me最好用的时机是让前端检查登入状态用，因为4字头就代表没登入
假如 200 就可以接着画使用者资料了。
然后我没有考虑 JWT, 因为 JWT 里的资讯本来就比较额外。