推 shter: 老實說開頭兩例我還滿不喜歡 /users/1 這種風格的03/11 21:45
→ bibo9901: 奇怪. 難道有人覺得Get(User, 1)是很直覺的寫法嗎?03/11 21:45
→ shter: 因為這局限了查詢的層次，我要找就一定要 /users/1 底下找03/11 21:46
→ bibo9901: 任何人寫程式都是覺得 User.get(1) 比較直覺吧? 為什麼03/11 21:46
→ bibo9901: 變HTTP時就會自動想要"RESTful"?03/11 21:46
→ bibo9901: 說白了就是HTTP協定本來就不是為了API設計，只是方便易03/11 21:47
→ bibo9901: 用所以流行而已. 又"剛好" HTTP methods 對應了最常見的03/11 21:48
→ bibo9901: 幾種操作, 僅此而已. 沒必要把URI硬套"資源導向設計"03/11 21:49
推 shter: 不知何時開始，Web變的很重視 router 這種東西03/11 21:51
放心啦
以後剩下/graphQL而已XD
※ 編輯: ripple0129 (115.82.1.106), 03/11/2019 21:53:30
→ shter: 寫 users/1 變的像寫地址一樣，縣市/鄉鎮市區/路/段/號/樓03/11 21:52
→ shter: 可是你還是要看 Doc 才能操作 API03/11 21:53
→ shter: 不然你不知道每一層 / 底下代表的是什麼意思03/11 21:54
→ shter: 這樣跟傳統 ?search 看 Doc 查變數名稱沒啥不同03/11 21:54
→ bibo9901: 像你舉的例子 /user/group/1, 到底是 "user之下的group"03/11 21:54
→ bibo9901: 還是 "在group1裡的user"? 1-1, 1-n, n-1, n-n 的關係跟03/11 21:55
→ bibo9901: 本無法表達, 最後還不是要查doc. 既然都要查doc, 寫成03/11 21:55
→ bibo9901: /get_user_by_group/1 又有何防? 還更加清楚03/11 21:56
→ shter: 總覺得可能跟物件導向習慣一路 .下去還是 -> 指過去一樣吧03/11 21:56
推 shter: graphQL 讓我想到乾脆把整串JSON base64丟來丟去的日子 03/11 22:03
→ bibo9901: graphQL有spec,SAOP,JSON-RPC,XML-RPC都是協定(有spec) 03/11 22:09
→ bibo9901: REST沒有spec, 就是風格建議而已, 為什麼? 因為定出來就 03/11 22:09
→ bibo9901: 不夠簡單了. 03/11 22:10
推 longlongint: 我比較喜歡 mov je 03/11 22:11
→ alan3100: ..舉例錯誤呀 是/groups/{groupId}/users 03/11 22:40
→ CaptainTeemo: /get_user_by_group/1 是很糟糕的設計，而且使用 HA 03/12 05:51
→ CaptainTeemo: TEOAS 可以減少頻繁查 doc 03/12 05:51
推 goodblessu: 如果把session存在另一台redis，這樣算不算無狀態 03/12 08:14
→ SuM0m0: 頭一次看過有人用命名風格定義RESTful 03/12 11:38
推 csieflyman: 請問大家何時使用單數或複數? 例如 /users 是用複數03/12 12:24
→ csieflyman: 但/users/1/friends 是否用單數比較合理 /user/1/fri03/12 12:24
→ csieflyman: ends03/12 12:24
推 csieflyman: 另一個問題是 batch api 就是允許一次 POST jsonArray03/12 12:32
→ csieflyman: 多筆資料 要怎麼突顯出來? 例如 /users/batch 或是 /03/12 12:32
→ csieflyman: users 然後再多描述要傳 jsonarray 此外如果習慣用03/12 12:32
→ csieflyman: 複數 是否會有人以為可以 POST 多筆資料?03/12 12:32
推 csieflyman: 最後一個問題 當有多個動作修改某個資源時 但卻只有一03/12 12:39
→ csieflyman: 個 PUT 可以表達時 是否只能在 URL 標示動詞? 或是有03/12 12:39
→ csieflyman: 更好的作法?03/12 12:39
推 MangoTW: 先推這篇有比較提到 pattern 了03/12 13:27
→ MangoTW: 樓上說的單複數問題 URL 是資源定址在 RESTful 正規化為03/12 13:29
→ MangoTW: collections/element 的形式所以你是在 users 集合裏新增 03/12 13:30
→ MangoTW: users/1 則是集合中的某單一資源 是合語意的 03/12 13:31
推 csieflyman: 我自己都是用複數 但有同事問我上面這幾個問題 我不 03/12 13:37
→ csieflyman: 知如何解釋比較好 主要是 /users/1/friends 為何不是 03/12 13:37
→ csieflyman: 單數? 畢竟只是針對 user 1 這1個人的朋友做操作 03/12 13:37
推 csieflyman: 雖然大家對Restful 風格有一些共識了 但細節上還是會 03/12 13:40
→ csieflyman: 有人有不同的想法 03/12 13:40
細節本來就沒有嚴謹定義了
只是convention 大家都用複數
你要用單數也沒人可以說錯
但這個範例我個人覺得friends是複數啊
users/1的朋友們
users/1/friends/2這樣才覺得是單數
※ 編輯: ripple0129 (115.82.1.106), 03/12/2019 13:51:34
→ alan3100: 就只是你跟你同事腦袋轉不過來而已 你可以google沒s的少 03/12 13:50
→ csieflyman: friends是複數沒錯 我指的是users是否應該是單數 user 03/12 13:57
→ csieflyman: 我後來是跟他說 我看 Web API: the good parts 這本 03/12 14:01
→ csieflyman: 書 大多數人用複數 但我覺得用多數法則的理由壓人是否 03/12 14:01
→ csieflyman: 會讓人不服氣 03/12 14:01
→ brucetu: flyman大 因為/users/傳回多筆 /users/1 傳回一個user 03/12 15:35
→ brucetu: /users/1/something 就是根據這個user再往下取資料 03/12 15:35
→ brucetu: 如果這個something是一個集合 就用複數 03/12 15:36
→ brucetu: 因為這樣比較符合語意不單純是多數人使用的問題 03/12 15:36
→ brucetu: 就好像一個json描述的資源 , 集合通常用複數命名 03/12 15:37
推 bibo9901: 爭這個就好像回字有四種寫法一樣 03/12 16:07
→ ku399999: 一般用users/1 我覺得一來表示對這操作id是required,二 03/14 09:40
→ ku399999: 來明確表示整個系統只會有一個id=1的item 03/14 09:40
→ infixman: user們的1號的friend們的1號 03/19 07:25
→ infixman: 既然是“們”，加個s不是理所當然? 03/19 07:26