個人見解 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/m.aspx?n=bbs/Soft_Job/M.1611670395.A.AAB.html