个人见解
1. 语义上拿不到特定的资源，所以不会使用这个。
2. 用 me 的机会通常是会将 me 放在最前面，因为 me 最大。另外依照前端画面呈现来处理的话，如果 me 跟指定 userid 的画面一样的话，那用 me 的 shortcut 只是让自己更困扰而已。
3. 偏好用这个，比较符合定义，但要注意一下有些开发者可能会把 profile 拿掉，我自己是觉得都可以。
jwt 这部分跟 auth 比较有关，除非你是用 me，要不然其实应该可以不用考量这个。
额外提一下，把 me 放在网址上的做法，有时候会是 302 转址回 userid，这也要看画面设计而定。
以前刚开始学 RESTful 的时候蛮爱看 ihower 的文章，也推荐去看看。
https://ihower.tw/rails/restful.html
※ 引述《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 下没有指定对象又感觉很怪，毕竟 use
: rs 是复数
: 假设 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 来用，
: 谢谢