Re: [請益] RESTful API 身份設計問題

※ 引述《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 裡的資訊本來就比較額外。

--
人紅是非多，活益比非多。

--