Re: [請益] 所以,到底什麼是RESTful API?

看板Soft_Job作者 (perry tsai)時間6年前 (2019/03/11 21:26), 6年前編輯推噓12(12推 0噓 50→)
留言62則, 12人參與, 6年前最新討論串3/8 (看更多)
很多人以為 /users?id=1 改成 /users/1 就是Restful了 Restful是個風格 不過不是改個route, controller樣貌就叫Restful 以前自己在看的時候 比較難理解的個人覺得有兩個地方 第一就是資源點觀念 先來講講上面的觀念差異 /users?id=1 用資源點的觀念來看 就是資源點在/users 我要從users中query出id是1的user 所以說不是有parameter的就不是Restful 一樣能用資源點的觀念解釋 /users/1 這個1代表什麼自行定義吧 如果1代表的是group的話呢 users/1就是users被定義於group 1的資源點 可能也是多數也可以再用parameter query它 就像users/1?age<10 資源點就是這樣的概念 所以不是單純route的樣貌就決定是不是Restful 當然多數我們在設計時還是習慣會多個提醒 弄成這樣/users/group/1 照這樣講好像怎樣解釋都行的通？ 當然不是這樣子 資源點要是名詞 當有route被設計成 /get-user-password?account=abc 這樣的設計就偏離Restful了 因為帶有動詞的意味 第二個比較難理解就是無狀態 無狀態的定義就是你每次的request 都跟你之前的request無關 說的這麼複雜直接講白點就是 不要用session啦 過往設計可能會有第一次request 存點資料在session 下次request可能拿來用 不過這就背離Restful啦 而無狀態的好處是很明顯的 因為沒有狀態server只是取得資源點的地方 所以可以輕鬆的達成 多台Server提供服務 你每次的request連接到哪一台都沒差 要判斷你的設計是不是無狀態的 單純就考量這一點即可 能否Server多開後 同一使用者的Request 就算輪著一台一台戳也不會有問題 其他的觀念 個人覺得都算容易理解也不用贅述了 當然由於Restful沒明確指示做法 這是我個人解讀 覺得有誤也請指正了 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 115.82.1.106 ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1552310788.A.1B9.html
推
03/11 21:45, 6年前 , 1F
老實說開頭兩例我還滿不喜歡 /users/1 這種風格的
03/11 21:45, 1F
→
03/11 21:45, 6年前 , 2F
奇怪. 難道有人覺得Get(User, 1)是很直覺的寫法嗎?
03/11 21:45, 2F
→
03/11 21:46, 6年前 , 3F
因為這局限了查詢的層次，我要找就一定要 /users/1 底下找
03/11 21:46, 3F
→
03/11 21:46, 6年前 , 4F
任何人寫程式都是覺得 User.get(1) 比較直覺吧? 為什麼
03/11 21:46, 4F
→
03/11 21:46, 6年前 , 5F
變HTTP時就會自動想要"RESTful"?
03/11 21:46, 5F
→
03/11 21:47, 6年前 , 6F
說白了就是HTTP協定本來就不是為了API設計，只是方便易
03/11 21:47, 6F
→
03/11 21:48, 6年前 , 7F
用所以流行而已. 又"剛好" HTTP methods 對應了最常見的
03/11 21:48, 7F
→
03/11 21:49, 6年前 , 8F
幾種操作, 僅此而已. 沒必要把URI硬套"資源導向設計"
03/11 21:49, 8F
推
03/11 21:51, 6年前 , 9F
不知何時開始，Web變的很重視 router 這種東西
03/11 21:51, 9F
放心啦 以後剩下/graphQL而已XD ※ 編輯: ripple0129 (115.82.1.106), 03/11/2019 21:53:30
→
03/11 21:52, 6年前 , 10F
寫 users/1 變的像寫地址一樣，縣市/鄉鎮市區/路/段/號/樓
03/11 21:52, 10F
→
03/11 21:53, 6年前 , 11F
可是你還是要看 Doc 才能操作 API
03/11 21:53, 11F
→
03/11 21:54, 6年前 , 12F
不然你不知道每一層 / 底下代表的是什麼意思
03/11 21:54, 12F
→
03/11 21:54, 6年前 , 13F
這樣跟傳統 ?search 看 Doc 查變數名稱沒啥不同
03/11 21:54, 13F
→
03/11 21:54, 6年前 , 14F
像你舉的例子 /user/group/1, 到底是 "user之下的group"
03/11 21:54, 14F
→
03/11 21:55, 6年前 , 15F
還是 "在group1裡的user"? 1-1, 1-n, n-1, n-n 的關係跟
03/11 21:55, 15F
→
03/11 21:55, 6年前 , 16F
本無法表達, 最後還不是要查doc. 既然都要查doc, 寫成
03/11 21:55, 16F
→
03/11 21:56, 6年前 , 17F
/get_user_by_group/1 又有何防? 還更加清楚
03/11 21:56, 17F
→
03/11 21:56, 6年前 , 18F
總覺得可能跟物件導向習慣一路 .下去還是 -> 指過去一樣吧
03/11 21:56, 18F
推
03/11 22:03, 6年前 , 19F
graphQL 讓我想到乾脆把整串JSON base64丟來丟去的日子
03/11 22:03, 19F
→
03/11 22:09, 6年前 , 20F
graphQL有spec,SAOP,JSON-RPC,XML-RPC都是協定(有spec)
03/11 22:09, 20F
→
03/11 22:09, 6年前 , 21F
REST沒有spec, 就是風格建議而已, 為什麼? 因為定出來就
03/11 22:09, 21F
→
03/11 22:10, 6年前 , 22F
不夠簡單了.
03/11 22:10, 22F
推
03/11 22:11, 6年前 , 23F
我比較喜歡 mov je
03/11 22:11, 23F
→
03/11 22:40, 6年前 , 24F
..舉例錯誤呀 是/groups/{groupId}/users
03/11 22:40, 24F
→
03/12 05:51, 6年前 , 25F
/get_user_by_group/1 是很糟糕的設計，而且使用 HA
03/12 05:51, 25F
→
03/12 05:51, 6年前 , 26F
TEOAS 可以減少頻繁查 doc
03/12 05:51, 26F
推
03/12 08:14, 6年前 , 27F
如果把session存在另一台redis，這樣算不算無狀態
03/12 08:14, 27F
→
03/12 11:38, 6年前 , 28F
頭一次看過有人用命名風格定義RESTful
03/12 11:38, 28F
推
03/12 12:24, 6年前 , 29F
請問大家何時使用單數或複數? 例如 /users 是用複數
03/12 12:24, 29F
→
03/12 12:24, 6年前 , 30F
但/users/1/friends 是否用單數比較合理 /user/1/fri
03/12 12:24, 30F
→
03/12 12:24, 6年前 , 31F
ends
03/12 12:24, 31F
推
03/12 12:32, 6年前 , 32F
另一個問題是 batch api 就是允許一次 POST jsonArray
03/12 12:32, 32F
→
03/12 12:32, 6年前 , 33F
多筆資料 要怎麼突顯出來? 例如 /users/batch 或是 /
03/12 12:32, 33F
→
03/12 12:32, 6年前 , 34F
users 然後再多描述要傳 jsonarray 此外如果習慣用
03/12 12:32, 34F
→
03/12 12:32, 6年前 , 35F
複數 是否會有人以為可以 POST 多筆資料?
03/12 12:32, 35F
推
03/12 12:39, 6年前 , 36F
最後一個問題 當有多個動作修改某個資源時 但卻只有一
03/12 12:39, 36F
→
03/12 12:39, 6年前 , 37F
個 PUT 可以表達時 是否只能在 URL 標示動詞? 或是有
03/12 12:39, 37F
→
03/12 12:39, 6年前 , 38F
更好的作法?
03/12 12:39, 38F
推
03/12 13:27, 6年前 , 39F
先推這篇有比較提到 pattern 了
03/12 13:27, 39F
→
03/12 13:29, 6年前 , 40F
樓上說的單複數問題 URL 是資源定址在 RESTful 正規化為
03/12 13:29, 40F
→
03/12 13:30, 6年前 , 41F
collections/element 的形式所以你是在 users 集合裏新增
03/12 13:30, 41F
→
03/12 13:31, 6年前 , 42F
users/1 則是集合中的某單一資源 是合語意的
03/12 13:31, 42F
推
03/12 13:37, 6年前 , 43F
我自己都是用複數 但有同事問我上面這幾個問題 我不
03/12 13:37, 43F
→
03/12 13:37, 6年前 , 44F
知如何解釋比較好 主要是 /users/1/friends 為何不是
03/12 13:37, 44F
→
03/12 13:37, 6年前 , 45F
單數? 畢竟只是針對 user 1 這1個人的朋友做操作
03/12 13:37, 45F
推
03/12 13:40, 6年前 , 46F
雖然大家對Restful 風格有一些共識了 但細節上還是會
03/12 13:40, 46F
→
03/12 13:40, 6年前 , 47F
有人有不同的想法
03/12 13:40, 47F
細節本來就沒有嚴謹定義了 只是convention 大家都用複數 你要用單數也沒人可以說錯 但這個範例我個人覺得friends是複數啊 users/1的朋友們 users/1/friends/2這樣才覺得是單數 ※ 編輯: ripple0129 (115.82.1.106), 03/12/2019 13:51:34
→
03/12 13:50, 6年前 , 48F
就只是你跟你同事腦袋轉不過來而已 你可以google沒s的少
03/12 13:50, 48F
→
03/12 13:57, 6年前 , 49F
friends是複數沒錯 我指的是users是否應該是單數 user
03/12 13:57, 49F
→
03/12 14:01, 6年前 , 50F
我後來是跟他說 我看 Web API: the good parts 這本
03/12 14:01, 50F
→
03/12 14:01, 6年前 , 51F
書 大多數人用複數 但我覺得用多數法則的理由壓人是否
03/12 14:01, 51F
→
03/12 14:01, 6年前 , 52F
會讓人不服氣
03/12 14:01, 52F
→
03/12 15:35, 6年前 , 53F
flyman大 因為/users/傳回多筆 /users/1 傳回一個user
03/12 15:35, 53F
→
03/12 15:35, 6年前 , 54F
/users/1/something 就是根據這個user再往下取資料
03/12 15:35, 54F
→
03/12 15:36, 6年前 , 55F
如果這個something是一個集合 就用複數
03/12 15:36, 55F
→
03/12 15:36, 6年前 , 56F
因為這樣比較符合語意不單純是多數人使用的問題
03/12 15:36, 56F
→
03/12 15:37, 6年前 , 57F
就好像一個json描述的資源 , 集合通常用複數命名
03/12 15:37, 57F
推
03/12 16:07, 6年前 , 58F
爭這個就好像回字有四種寫法一樣
03/12 16:07, 58F
→
03/14 09:40, 6年前 , 59F
一般用users/1 我覺得一來表示對這操作id是required,二
03/14 09:40, 59F
→
03/14 09:40, 6年前 , 60F
來明確表示整個系統只會有一個id=1的item
03/14 09:40, 60F
→
03/19 07:25, 6年前 , 61F
user們的1號的friend們的1號
03/19 07:25, 61F
→
03/19 07:26, 6年前 , 62F
既然是“們”，加個s不是理所當然?
03/19 07:26, 62F
‣ 更多 ripple0129 的文章
文章代碼(AID): #1SXc846v (Soft_Job)
討論串 (同標題文章)
完整討論串 (本文為第 3 之 8 篇)：
排序： 最新先 | 最舊先 | 留言數
在新視窗開啟完整討論串 (共8篇)
‣ 更多 ripple0129 的文章
文章代碼(AID): #1SXc846v (Soft_Job)