看板 Soft_Job 關於我們 聯絡資訊
※ 引述《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 裡的資訊本來就比較額外。 -- 人紅是非多,活益比非多。 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 111.248.47.164 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1611796477.A.192.html
yukang: 我覺得怕me 重復可能只有 ptt 才會發生 01/28 09:42
yukang: 基本的帳號長度都超過2碼 01/28 09:42
bill0205: id如果是int其實就還好 如果是uuid就有可能了XD 01/28 09:48
CMJ0121: p果是 RESTFul API 帳號相關還是不建議用可以列舉的 int 01/28 13:53
csieflyman: 我習慣用 /users/{userId}/profile 及 /users/myProfi 01/28 15:36
csieflyman: le 因為 userId 會自動填入變數 型態可能是 long 或 u 01/28 15:36
csieflyman: uid 所以不能直接寫死 me 01/28 15:36