Re: [請益] RESTful API 身份設計問題
個人見解
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
--
問個簡單問題 get api/events,怎麼區別是拿全部 events
還是拿你 jwt token 登入身份的 events,一般範例拿到的
講的都是登入後的數據,範例也沒看到 api/v1/me/events
該怎麼處理才是良好的 for you or for all 的設計
我主要是以前端畫面為主,後端擴充性為輔。一樣,如果你的
服務是像 kktix 一樣放各種 events 在首頁,那就用 /event
s,但如果你是要看我的公開 events 就會打 /kewang/events
,你的公開 events 就是 /chan15/events。如果你有一頁是
看自己的所有 events ,而且畫面差異大就打 /me/events,
因為自己還可以看 private 的 events
想看範例 /events 還是要指拿到全部 不然這功能就不見了
會拿到自己的或許是權限限制下不准許拿到額外的或是拿全
部沒有意義吧
2
在 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 會很衰10
首Po各位好,我正在設計公司的 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
33
Re: [討論] API沒資料,回200還是404比較好嗯,我想兩位的建議可以寄信向 GitHub 和 Atlassian 這兩間公司說明一下,或許可以 幫他們團隊縮減人力。 當查詢資源不存在時返回 HTTP Code 404:25
[心得] 什麼是 gRPC,架構上為什麼要使用 gRPC影片: 由於上一支影片是介紹『三種好用的 gRPC 測試工具[1]』,這次就來錄製什麼是 gRPC,以及為什麼我們要導入此項技術 [1]: 由於團隊專案越來越多,共用的模組跟服務需求也越來越頻繁,故需要導入 gRPC 協定來 解決服務跟服務之間溝通的成本。用簡單的 10 分鐘來跟大家介紹什麼是 gRPC,以及13
[心得] 為什麼要學 GraphQL?來聊個簡單的議題? 『為什麼要學 GraphQL?』 部落格好讀版: 身為網站工程師,您不能不知道什麼是 GraphQL,這是一個前端跟後端溝通的 API Query 語法,大幅改善了前後端的合作模式,這篇會跟大家介紹為什麼麼要學 GraphQL, 以及整理出三大 GraphQL 優勢,讓大家了解跟傳統 Restful API 有什麼不同。當然不是9
[請益] TD 第一次登入的問題各位大大好~ 今天剛收到TD開戶完成通知信 在TD頁面輸入UserID 以及密碼登入後 會看到以下畫面6
Re: [請益] 專精前端(或後端)vs全端工程師之前剛好有一份工作是全端,我不知道是否會趨勢化,但全端不一定是一人包前後的案子 事實上那是一份不小的專案,前後端各有數人在開發,甚至客戶 App 也會來串機器 簡單介紹一下那個專案架構 我方開發 web 前端,機器上跑大量 C 的程式,需要把既有 command line 東西視覺化 為了達成雲端操作,所以需要有一個全端來設計 API + SDK2
Re: [閒聊] Roguelike最重視的元素是?一般來說Roguelike在開發者側看法有以下幾個重要的重點 1.環境自動生成 不論是道具,怪物,事件等等的要素。能有自動生成的話玩家就不會膩 2.懲罰 玩家一但嘗試失敗,無法利用存檔機制重來。做了就要負責1
Re: 請益Request爬蟲追了一天動漫來回點東西, 轉生公主天才千金好香,槍神畫面好屌 遇到問題時除了試著使用其它工具或做法, 還能做的 - 或許也是應該先做的 - 是瞭解問題。 或許你是後端工程師,對前端不熟,那看看你們公司有沒有前端工程師可以問,