推 Soarwind: 推~ 很清楚, RESTful 是這樣 06/22 22:25
推 CMJ0121: 推 06/22 22:35
推 cip604: 推 06/22 22:59
推 yehzu: 推!認同此篇概念 06/22 23:03
推 lovdkkkk: 推 不過最後的 403 404 好像反了 06/22 23:05
推 devilkool: 推 06/22 23:22
推 justaID: 樓上,404 403 的例子應該沒有講反?先驗權限回403,缺 06/22 23:24
→ justaID: 乏權限的連資源是否存在都不該讓 hacker 直到很合理 06/22 23:24
抱歉,這裡的確是我剛剛數字寫反了…我修
改了一下並把你想要說的補充上去
→ justaID: *樓樓上06/22 23:24
→ justaID: *知道 (自動選字QQ06/22 23:25
→ justaID: 推這篇對 REST 描述得滿清楚06/22 23:26
推 viper9709: 推06/22 23:27
推 justaID: 我剛剛沒有注意 GitHub 原文那段,原來 GitHub in some06/22 23:47
→ justaID: places 沒權限時回404,我個人本來以為應該優先回 40306/22 23:47
→ justaID: 比較合理 (無論背後資源是否存在,都回 403 並不會讓 u06/22 23:47
→ justaID: nauthorized user 知道資源到底在不在),推測也許考量06/22 23:47
→ justaID: 觀點是:看到 403,hacker 會覺得背後資源有可能存在,06/22 23:47
→ justaID: 而繼續找其他方法突破 auth;但看到 404 很大機率是資源06/22 23:47
→ justaID: 真的不存在,effort 取捨下會放棄 hack 這個資源,避免06/22 23:47
→ justaID: hack 半天一場空06/22 23:47
無論「資源是否存在都回 403」
這件事情卡到的是有公開倉庫:
存在的公開倉庫有權限 200
存在的公開倉庫沒權限 200
存在的私有倉庫有權限 200
存在的私有倉庫沒權限 403 -> 被猜出
不存在的公開倉庫 404 -> 合理
不存在的公開倉庫 403 -> 不合理
推 Y78: 推06/22 23:57
推 justaID: 謝謝原po的列舉解說,以 Github 的 case 來說確實卡到了 06/23 00:44
→ justaID: 公開倉庫 和私有倉庫 是同樣的 path pattern,無法在判 06/23 00:44
→ justaID: 斷倉庫是否存在前就先以 403 阻擋 06/23 00:44
推 genius945: 說得很清楚,推 06/23 01:10
推 Romulus: GitHub不要說REST了,就連網頁介面照樣丟404 XD 06/23 01:23
推 YYYero: 推 06/23 01:43
推 LeoSW: 推這篇,寫得很清楚 06/23 08:15
噓 DrTech: 原文搞錯了。重點不在查詢資源存在不存在。而是你認為Clie 06/23 08:34
→ DrTech: nt的Request行為,是正常還是預期外的error。4xx開頭是 er 06/23 08:34
→ DrTech: ror 。2xx開頭是 Info。 06/23 08:34
→ DrTech: 請參考RFC2616。 06/23 08:34
好了啦,你要扯國際規範我拿給你呀:
https://www.rfc-editor.org/rfc/rfc7231#section-6.3.1
https://www.rfc-editor.org/rfc/rfc7231#section-6.3.5
The 404 (Not Found) status code indicates
that the origin server did not find a
current representation for the target
resource or is not willing to disclose that
one exists.
符合上述我說的 GitHub 設計時的兩種狀況
:
1. 資源不存在
2. 存在但不想被洩漏
拜託你要酸要噓之前,更新一下自己的認知
和當前規範有沒有差異好嗎?自己動手翻一
下你說的 RFC2616 也寫了:
https://i.imgur.com/ngpNzDp.png
Obsoleted by: 7230, 7231, 7232, 7233,
7234, 7235
拿明朝的劍斬清朝的官?但其實不論是你說
的 RFC2616 還是 RFC7231/RFC9110 都也沒
說錯,與微軟還有 GitHub 設計的狀況都不
謀而合。是你誤解了規範的說法,並忽略我
前面說的「在 REST 設計風格角度」下去看
待事情。
---
你說的「重點不在查詢資源存在不存在。而
是妳認為 Client 的請求行為,是正常還是
預期外的錯誤」
是你沒搞清楚吧?對於今天 Client 請求一
個不存在的 /users/<USERNAME>來說,當這
個 <USERNAME> 不存在時,就是你所說的預
期外的錯誤。
因為在 REST 設計的視角上,這是訪問一個
不存在的資源,返回 404一點懸念都沒有,
他正是你說的預期外的錯誤,在這個設計風
格下面,要以「資源」和「操作」來考量。
(拜託再往上翻一下國際規範,就我有上
色那一部分)
---
在應用場景下,他預期的是你先透過:
/users 獲取 <USERNAME>
/users/<USERNAME>/followers 獲取 <USERNAME>
/posts/<POST_ID>/authors 獲取 <USERNAME>
...
先拿到 <USERNAME> 才去打 /users/<USERNAME>
---
這是 REST 設計風格的不友善之處,因為拆
分路徑和設計返回的內容,切分粒度太細跟
切分粒度太粗,要嘛是我一下就拿到一大包
資料,有很多不必要的資訊,要嘛是我要層
層打好幾個請求才能拿到需要的資訊:
‧前者塞太多東西,費流
‧後者跨多個請求,佔線
可以改用 GraphQL 設計 API。
也可以單純用 RPC 方式處理。
推 zxc8787: 推 06/23 08:55
推 BBSealion: 讚讚 06/23 08:56
推 suibo: 推 06/23 09:37
推 zxc6414189: 推 06/23 10:16
推 longlyeagle: nice nice 06/23 10:19
推 TheWhack: 原文那2位版友是在指API回空資料應該要用200而非404吧? 06/23 11:20
→ TheWhack: 就是對應到原po的"空無一人,並不是沒有清單"這項 06/23 11:20
→ alan3100: /users/<USERNAME> 已經指定user卻找不到是種錯誤回404 06/23 11:57
→ alan3100: /users/<USERNAME>/followers 沒有是一種正常情況回200 06/23 11:57
推 hegemon: 這個是萬年議題了...怎麼沒有人把204一起拉來參戰? 國外 06/23 12:42
→ hegemon: 都是200, 204, 404大亂鬥的 06/23 12:42
推 Romulus: 可是明明就有啊.204 06/23 13:13
推 lturtsamuel: 原文在問的不是你這個找不到user的狀況吧 比較像是有 06/23 13:37
→ lturtsamuel: 這個user但他沒有repo 06/23 13:37
→ Hsins: 原 po 只有說沒資料吧? /users/<USERNAME> 當 USERNAME 06/23 13:45
→ Hsins: 不在資料庫中,也是沒資料... 06/23 13:46
推 TheWhack: 可能要釐清最原po的"沒資料",是指null,還是{}或[] ? 06/23 14:09
→ Hsins: 所以應該引導他去思考這件事情,而不是直接就說 404 或 200 06/23 14:48
→ Hsins: 的直接方案,這個從那篇的推文跟我這篇回文,我有將情境和 06/23 14:49
→ Hsins: 前提敘述出來的 06/23 14:49
→ ssccg: 404和403的部分其實兩個都可以,只要統一即可 06/23 15:07
→ ssccg: 讓存在但沒權限和不存在兩個狀態無法分辨即可 06/23 15:08
→ ssccg: RFC 403的理由不一定要跟權限有關,而404也可以是故意隱藏 06/23 15:11
→ ssccg: 當然如果網站有公開的部分,統一成404比較合理 06/23 15:13
推 davidsky: 下面寫得不錯但是上面酸他們沒必要 他們只用一行字要怎 06/23 17:00
→ davidsky: 怎麼表達404不該用在[] 06/23 17:00
→ davidsky: 而且我看原標題也會覺得再問array為空 單一資源沒有的話 06/23 17:01
→ davidsky: 不太可能會想用200 06/23 17:01
→ Hsins: 這麼說吧,我看標題也會這麼認為,而且也同意這樣的狀況是 06/23 17:15
→ Hsins: 200 並回傳空值,但是看到文章內容,會提到 404 通常是與 R 06/23 17:15
→ Hsins: EST 風格的這種資源不存在混淆(不論是發文者或是他看到這 06/23 17:15
→ Hsins: 樣實作的那個人)。 06/23 17:15
→ Hsins: 推文的可以選擇回文,也可以選擇推多行文字。直接用一行字 06/23 17:18
→ Hsins: 不負責任地表達又說可以 fire 人,還真不知道是我比較酸還 06/23 17:18
→ Hsins: 是他們比較酸? 06/23 17:18
推 janbarry168: 推 06/23 19:17
推 zegas: 推 06/23 19:55
推 wwfwwf: 推 06/23 20:57
噓 DrTech: 原文拿Restful慣例(非國際標準),來戰國際標準。搞錯優先 06/23 21:49
→ DrTech: 權啦。 06/23 21:49
你是不是搞錯什麼了?你所說的國際標準考
慮到 REST 的使用,在 2014 年增修了內容
,然後你一直說他增添的內容不符合國際標
準,大叔你是在哈囉?
https://i.imgur.com/r3WxHVV.png
不要只是噓文啊,拿你的國際標準寫篇文反
駁一下呀。我先跟你說在 RFC 7231 的第二
章就引用 [REST] 添加了資源(resource)
和表現層(Representations)的敘述。
拿出點證據來嘛!當大家沒看過文件?「說
話科學點,是身為工程師最基本的吧?」我
記得這好像是你說的?
推 iamOsaka: 推 06/23 22:09
推 lovdkkkk: 倒是講到個點了,之前就想回標準是方便大家對齊用的,不 06/23 23:02
→ lovdkkkk: 是權威鐵律,如果自己用標準感覺不方便可以不用符合,如 06/23 23:03
→ lovdkkkk: 果大家都照標準走都覺得不方便也可以修 06/23 23:03
→ lovdkkkk: 看到修文講到回一下 (飄走) 06/23 23:05
→ Hsins: 像是 Meta 家的就沒有很依照這篇提的 REST 風格(即使他們 06/23 23:07
→ Hsins: 宣稱是 REST API) 06/23 23:09
推 SMMIT: 推 詳細 06/23 23:24
→ mTwTm: 我覺得其實拿 RFC 2616 的敘述來佐證 API 設計很奇怪,他 06/24 03:08
→ mTwTm: 當下主要目的就是設計給 hypermedia 資源的存取,只是後來 06/24 03:08
→ mTwTm: 有些人決定也沿用這個來當 API 的協定當然現在就漸漸變成 06/24 03:08
→ mTwTm: 常見的做法。就是因為後來才借用當然就需要一個 adapter 06/24 03:08
→ mTwTm: 雖然不一定要是 rest 但不考慮中間這層直接去引用 http 的 06/24 03:08
→ mTwTm: 敘述我是覺得一定會因為文件資源跟資訊的目的不同而對不上 06/24 03:08
上面並不是拿 RFC 2616 來佐證設計,而是
拿修正後的 RFC 723X 來說明 REST 風格的
合理性。
在 RFC 2616 還可以看到 URL 和 URN 的描
述,在 RFC 723X 就幾乎回歸到更為抽象的
URI 上了,更加強調「資源」的抽象概念。
你所謂中間那層的 adapater 其實就是文件
中對於 representation 的描述,而這也是
REST 風格的一部分:
「一個 URI 對應一種資源」
不論今天這個資源是一張圖片、一段文字、
一個頁面,都對應成一個 URI來表示。你要
提供資料庫中的使用者資訊、文章資訊,當
然也是可以,轉化成一個資源並對應,而在
目前多會以方便解析的結構化 JSON/XML 格
式表示這個資源。
另外必須補充一下,現代的客戶端並不是只
有網頁瀏覽器,如果都以瀏覽器的角度去看
的話,就很容易會因為你說的這個差異混淆
…
→ ssccg: RESTful的精神就是回歸hypermedia,而不是用cgi的角度在看 06/24 03:57
→ ssccg: 不管背後是個File system還是Web framework,URI呈現出來的 06/24 03:59
→ ssccg: 就是資源、就跟一個網址對應一個網頁都一樣 06/24 04:00
→ ssccg: 反過來說不把URI當資源而是API端點的話,根本不用分path 06/24 04:03
→ ssccg: 像一般RPC把要做什麼也都放在參數不是更單純不會有404? 06/24 04:07
→ ssccg: 就是在Web API多數分path有分GET、POST,有的時候用4xx有時 06/24 04:12
→ ssccg: 候又用body內自定義code,沒一個原則,才會有人提RESTful 06/24 04:14
→ ssccg: 用本來就存在、實作也大致符合標準的HTTP來當這原則 06/24 04:18
※ 編輯: Hsins (111.82.214.46 臺灣), 06/24/2022 09:22:36
→ mTwTm: 我的意思就是怎麼樣都應該拿後期的 RFC 而不是 2616 06/24 12:30
→ mTwTm: 也不是說一定要拿 RFC 但不能直接套用 2616 (回應科技博 06/24 12:31
→ mTwTm: 正是因為是不是從瀏覽器出發的這個差異所以看舊的 RFC 的 06/24 12:32
→ mTwTm: 時候要意識到當初他的設計不能用現代的方式自行解讀 06/24 12:32
推 fadeawaygod: 這篇才是正解,回200與204都是積非成是 06/24 15:07
推 Romulus: 我覺得MT是最被看破手腳的 大概可以想成他其他話題 06/24 16:26
→ Romulus: 很嗆可能也是用類似的一知半解就不知道在嗆什麼…… 06/24 16:26
推 mirror0227: 推 06/26 03:27