个人见解 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 来用， : 谢谢 ----- Sent from JPTT on my Google Pixel 3. -- 杂七杂八的kewang部落格 http://kewang.tw --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 114.136.127.46 (台湾) ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1611670395.A.AAB.html