PTT評價

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

看板Soft_Job標題[請益] RESTful API 身份設計問題作者
chan15
(ChaN)
時間推噓10 推:10 噓:0 →:34

各位好,我正在設計公司的 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 來用,謝謝

--

※ PTT 留言評論
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 122.116.234.173 (臺灣)
PTT 網址
※ 編輯: chan15 (122.116.234.173 臺灣), 01/26/2021 21:15:40

MOONY13501/26 21:36有要開放查其他人的話3應該好一點吧

MOONY13501/26 21:39你要開放可以查其他人為什麼要選2只是為了jwt token

MOONY13501/26 21:39的便利性?

MOONY13501/26 21:40然後你自己想想你的忘記密碼舉例 到底是針對自己 還是

MOONY13501/26 21:40開給後台操作人員做的

MOONY13501/26 21:422跟3其實可以不互斥 自己查自己的資訊內容跟

MOONY13501/26 21:42自己可以查別人的資訊內容肯定不一樣吧?

你好,2 跟 3 打架是指 route 的設計,teams/{team_id}/users/XXX/profile 雖然 XXX 有很多手腳可以動,譬如寫判斷 me 就是自己 me 以外是 uid 但我覺得變本末倒置

jinmin8801/26 21:48jwt是方便讓你知道執行者是誰,api多個me,有點多此一舉

對,但 users/profile 又有點奇怪...

bill020501/26 22:06我是給自己用就用1 畢竟表定是給自己 無需增加me

bill020501/26 22:06但是開放給其他人查就會用3

bill020501/26 22:07兩種並不互斥+1

這樣聽起來就是 for me: teams/{team_id}/users/profile for someone: teams/{team_id}/users/{user_id}/profile 這樣嗎

MOONY13501/26 22:11你的api其實沒考慮到是給'什麼權限'的人用,才會覺得好

MOONY13501/26 22:11像用法很奇怪

可以幫忙導正一下嗎 QQ

longlyeagle01/26 22:183

bill020501/26 22:19偷偷問 如果說表定API是給自己用 那1 的users/profile

bill020501/26 22:20這語法好像有點怪怪的?

bill020501/26 22:20(我是想users是複數 但指向自己 是複數嗎@@)

You got the point

SHANGOYANYI01/26 22:41選3 然後最後面’profile‘可以省略 另外有user_

SHANGOYANYI01/26 22:41id情況下前面多teams那一層的設計會變成階層關係

SHANGOYANYI01/26 22:41對未來擴充彈性(例如:user可加入多team、user尚

SHANGOYANYI01/26 22:41未加入任何team)的影響可能要考慮一下

Dommgifer01/26 22:42把角色權限考慮進去 應該就會有不同的想法了

online13501/26 23:043 你可以去查 Laravel官方網站 裡面有寫

好的,謝謝

rounivin01/26 23:29不懂3和失去比對jwt token 便利性有什麼關係

因為假設是查自己了,那 {user_id} 不需要存在,從 jwt token 就可以拿到 id 了 所以網路上的範例多半 api/v1/events 是指 jwt token user 的 personal event 那反過來講,我 api/v1/events 萬一是要給全部的人看不鎖登入的話該怎麼辦 我現在就是怎麼從網址就可以清楚表示這個 resource 是拿登入者自己還是全部的數據而困擾

※ 編輯: chan15 (122.116.234.173 臺灣), 01/27/2021 00:47:08

TheWhack01/27 01:091或3,你開的3感覺很充裕了,不要用me

l7th01/27 03:07/teams/{team_id}/me & teams/{team_id}/users/{id}

MOONY13501/27 04:49例如你的忘記密碼要用那個,指定user id的忘記密碼代表

MOONY13501/27 04:49你可以幫別人改資料 你覺得這是誰可以做的事情? 管理員

MOONY13501/27 04:49可以啊 所以你用管理員的思維跟自己可以改自己的,這兩

MOONY13501/27 04:49種路徑不就不會衝突,因為是給不同權限的人用的

MOONY13501/27 04:52Identify/forget-password & users/{his}/forget-passwo

MOONY13501/27 04:52rd

MOONY13501/27 04:53his->uid

superpai01/27 05:36其實我覺得2是最好的,me就是一個特殊userid啊,沒有跟3

superpai01/27 05:36打架的感覺

bill020501/27 09:50我意思是 users是user的複數 但是取自己的profile

bill020501/27 09:50應該是單數吧?!

superpai01/27 12:01不懂你的意思,/users/userid 一樣也是單一user

petercoin01/27 15:23/users/userid/profile比較符合針對單一使用者的意思吧

petercoin01/27 15:23/users/profile看起來就是要撈所有使用者的profile?

bill020501/27 16:09我問題是只針對原PO的1的狀況 就是P大所說的

bill020501/27 16:10看起來像是撈取所有使用者的profile

doranako01/27 21:43如果有開放查別人,3最好,不然還要多寫個api,如果沒

doranako01/27 21:43開放查別人只能拿到自己,那前面路徑應該要改一下