作者:
Hsins (翔)
2022-06-22 21:51:24: 推 rollr: 回404的可以 fired 了 06/22 19:54
: → moom50302: 回404來亂的嗎？ 06/22 20:45
嗯，我想兩位的建議可以寄信向 GitHub 和
Atlassian 這兩間公司說明一下，或許可以
幫他們團隊縮減人力。
當查詢資源不存在時返回 HTTP Code 404：
https://i.imgur.com/67gl9w8.png
https://i.imgur.com/Mysgpr4.png
[REF] https://docs.github.com/en/rest
[REF] https://docs.atlassian.com/ConfluenceServer/rest/7.18.1/#-getNodeById
作者:
CMJ0121 (請多指教!!)
2022-06-22 22:35:00推
作者:
cip604 (cip604)
2022-06-22 22:59:00推
作者:
yehzu (小葉~)
2022-06-22 23:03:00推！認同此篇概念
作者: justaID (快樂崇拜) 2022-06-22 23:24:00
樓上，404 403 的例子應該沒有講反？先驗權限回403，缺乏權限的連資源是否存在都不該讓 hacker 直到很合理*樓樓上*知道 （自動選字QQ推這篇對 REST 描述得滿清楚
作者: justaID (快樂崇拜) 2022-06-22 23:47:00
我剛剛沒有注意 GitHub 原文那段，原來 GitHub in someplaces 沒權限時回404，我個人本來以為應該優先回 403比較合理 （無論背後資源是否存在，都回 403 並不會讓 unauthorized user 知道資源到底在不在），推測也許考量觀點是：看到 403，hacker 會覺得背後資源有可能存在，而繼續找其他方法突破 auth；但看到 404 很大機率是資源真的不存在，effort 取捨下會放棄 hack 這個資源，避免hack 半天一場空
作者:
Y78 (Y78)
2022-06-22 23:57:00推
作者: justaID (快樂崇拜) 2022-06-23 00:44:00
謝謝原po的列舉解說，以 Github 的 case 來說確實卡到了公開倉庫 和私有倉庫 是同樣的 path pattern，無法在判斷倉庫是否存在前就先以 403 阻擋
作者:
Romulus (Säubern Mode)
2022-06-23 01:23:00GitHub不要說REST了，就連網頁介面照樣丟404 XD
作者: YYYero (YYYero) 2022-06-23 01:43:00
推
作者:
LeoSW (月夜飄雪)
2022-06-23 08:15:00推這篇，寫得很清楚
作者:
DrTech (竹科管理處網軍研發人員)
2022-06-23 08:34:00原文搞錯了。重點不在查詢資源存在不存在。而是你認為Client的Request行為，是正常還是預期外的error。4xx開頭是 error 。2xx開頭是 Info。請參考RFC2616。
作者:
zxc8787 (摸斗哈壓庫)
2022-06-23 08:55:00推
作者:
suibo (獻給阿爾吉儂的花束)
2022-06-23 09:37:00推
作者: zxc6414189 2022-06-23 10:16:00
推
作者: TheWhack (我是德華) 2022-06-23 11:20:00
原文那2位版友是在指API回空資料應該要用200而非404吧?就是對應到原po的"空無一人，並不是沒有清單"這項
/users/<USERNAME> 已經指定user卻找不到是種錯誤回404/users/<USERNAME>/followers 沒有是一種正常情況回200
作者:
hegemon (hegemon)
2022-06-23 12:42:00這個是萬年議題了...怎麼沒有人把204一起拉來參戰？ 國外都是200, 204, 404大亂鬥的
作者:
Romulus (Säubern Mode)
2022-06-23 13:13:00可是明明就有啊.204
原文在問的不是你這個找不到user的狀況吧 比較像是有這個user但他沒有repo
作者:
Hsins (翔)
2022-06-23 13:45:00原 po 只有說沒資料吧？ /users/<USERNAME> 當 USERNAME不在資料庫中，也是沒資料...
作者: TheWhack (我是德華) 2022-06-23 14:09:00
可能要釐清最原po的"沒資料"，是指null，還是{}或[] ?
作者:
Hsins (翔)
2022-06-23 14:48:00所以應該引導他去思考這件事情，而不是直接就說 404 或 200的直接方案，這個從那篇的推文跟我這篇回文，我有將情境和前提敘述出來的
作者:
ssccg (23)
2022-06-23 15:07:00404和403的部分其實兩個都可以，只要統一即可讓存在但沒權限和不存在兩個狀態無法分辨即可RFC 403的理由不一定要跟權限有關，而404也可以是故意隱藏當然如果網站有公開的部分，統一成404比較合理
作者:
davidsky (Alive)
2022-06-23 17:00:00下面寫得不錯但是上面酸他們沒必要 他們只用一行字要怎怎麼表達404不該用在[]而且我看原標題也會覺得再問array為空 單一資源沒有的話不太可能會想用200
作者:
Hsins (翔)
2022-06-23 17:15:00這麼說吧，我看標題也會這麼認為，而且也同意這樣的狀況是200 並回傳空值，但是看到文章內容，會提到 404 通常是與 REST 風格的這種資源不存在混淆（不論是發文者或是他看到這樣實作的那個人）。推文的可以選擇回文，也可以選擇推多行文字。直接用一行字不負責任地表達又說可以 fire 人，還真不知道是我比較酸還是他們比較酸？
作者: janbarry168 (貝瑞) 2022-06-23 19:17:00
推
作者:
zegas (電風扇啊啊啊啊啊啊啊)
2022-06-23 19:55:00推
作者:
wwfwwf (123)
2022-06-23 20:57:00推
作者:
DrTech (竹科管理處網軍研發人員)
2022-06-23 21:49:00原文拿Restful慣例(非國際標準)，來戰國際標準。搞錯優先權啦。
倒是講到個點了，之前就想回標準是方便大家對齊用的，不是權威鐵律，如果自己用標準感覺不方便可以不用符合，如果大家都照標準走都覺得不方便也可以修看到修文講到回一下 (飄走)
作者:
Hsins (翔)
2022-06-23 23:07:00像是 Meta 家的就沒有很依照這篇提的 REST 風格（即使他們宣稱是 REST API）
作者: SMMIT (Negan) 2022-06-23 23:24:00
推 詳細
作者: mTwTm (天) 2022-06-24 03:08:00
我覺得其實拿 RFC 2616 的敘述來佐證 API 設計很奇怪，他當下主要目的就是設計給 hypermedia 資源的存取，只是後來有些人決定也沿用這個來當 API 的協定當然現在就漸漸變成常見的做法。就是因為後來才借用當然就需要一個 adapter雖然不一定要是 rest 但不考慮中間這層直接去引用 http 的敘述我是覺得一定會因為文件資源跟資訊的目的不同而對不上
作者:
ssccg (23)
2022-06-24 03:57:00RESTful的精神就是回歸hypermedia，而不是用cgi的角度在看不管背後是個File system還是Web framework，URI呈現出來的就是資源、就跟一個網址對應一個網頁都一樣反過來說不把URI當資源而是API端點的話，根本不用分path像一般RPC把要做什麼也都放在參數不是更單純不會有404?
作者: mTwTm (天) 2022-06-24 12:30:00
我的意思就是怎麼樣都應該拿後期的 RFC 而不是 2616也不是說一定要拿 RFC 但不能直接套用 2616 （回應科技博正是因為是不是從瀏覽器出發的這個差異所以看舊的 RFC 的時候要意識到當初他的設計不能用現代的方式自行解讀
作者:
Romulus (Säubern Mode)
2022-06-24 16:26:00我覺得MT是最被看破手腳的 大概可以想成他其他話題很嗆可能也是用類似的一知半解就不知道在嗆什麼……