Re: [討論] API沒資料,回200還是404比較好
: 推 rollr: 回404的可以 fired 了 06/22 19:54: → moom50302: 回404來亂的嗎? 06/22 20:45
嗯,我想兩位的建議可以寄信向 GitHub 和
Atlassian 這兩間公司說明一下,或許可以
幫他們團隊縮減人力。
當查詢資源不存在時返回 HTTP Code 404:
https://i.imgur.com/67gl9w8.png
[REF] https://docs.github.com/en/rest
[REF] https://docs.atlassian.com/ConfluenceServer/rest/7.18.1/#-getNodeById
---
在往下展開之前,我必須說下面的內容是以
RESTful API 設計風格的角度去看待,實現
上還有其他的方式可以採用。
REST = Representational State Transfer
‧網路上的資源,透過 URI 與之對應
‧資源可以有不同的表現形式,透過請求時
攜帶的 Content-Type/Accept 指定
‧透過 HTTP 協議方法轉化資源狀態
在 RESTful 架構中,每一個 URI 對應一種
資源,所以設計上會避免路徑出現動詞(動
詞用以轉化資源狀態,以 HTTP 協議的方法
來對應),而以名詞呈現;加上資料庫中存
放資料通常為資料的集合,因此多採用複數
形式(多個用戶/多篇文章/多個倉庫…)
---
以 GitHub REST API (v3) 的設計來回應推
文中提到的幾個問題,舉例來說:
[GET] /users
獲取使用者清單
[GET] /users/<USERNAME>
獲取指定使用者資訊
‧如果 USERNAME 不存在,返回 404
[GET] /users/<USERNAME>/followers
獲取指定使用者的追蹤者
‧如果 USERNAME 下沒有追蹤者
返回 200 與空陣列
---
差異在於以 REST 設計時,倘若今天你要拿
到 USERNAME 去進行請求,會假定你已經知
道要拿這個使用者下面的資料了,如果是使
用者不存在,代表是 Client 的問題,企圖
存取沒有的資源,當然是 404。
而訪問指定 USERNAME 下面的追蹤者時,是
要獲取資源清單,所以這時的空陣列就是他
的清單,只是空無一人,並不是沒有清單,
自然是 200 表示請求成功。
至於有人問說返回 404 怎麼跟 API 不存在
作區別,其實從上述的範例看的出來,今天
的 <USERNAME> 相當於是查詢用的參數,訪
問這個資源的確不存在,查詢資源的 API的
確不存在,兩件事情都成立呀!
因為此時 REST 設計要告訴你的就是「路徑
不存在,路徑又對應資源,資源不存在」
---
另外提一下推文有的一些謬誤:
‧HTTP Status Code 中的 4xx 代表客戶端
錯誤,而 5xx 才是伺服器錯誤,所以系
統錯誤更不該返回 404…
‧在 REST 中用 GET 拿資料,而 204 其實
代表的是「請求成功,但沒有 BODY」,
這個比較常用在 DELETE 操作…
---
順帶提一下,規範跟設計上是需要做取捨的
,比如 GitHub 其中有一段關於授權認證的
敘述:
「Requests that require authentication
will return 404 Not Found, instead of
403 Forbidden, in some places. This is
to prevent the accidental leakage of
private repositories to unauthorized
users.」
當沒有授權的使用者去獲取倉庫清單時,即
使是沒有權限,也必須先考慮到隱私性所以
返回 404 而不是 403 避免私有倉庫被沒有
權限的人知道:
> 沒有權限,但訪問 A 倉庫拿到 403
> 可以猜出有個私有倉庫 A
> 但使用者其實不想讓人知道他有這個倉庫
--
推~ 很清楚, RESTful 是這樣
推
推
推!認同此篇概念
推 不過最後的 403 404 好像反了
推
樓上,404 403 的例子應該沒有講反?先驗權限回403,缺
乏權限的連資源是否存在都不該讓 hacker 直到很合理
抱歉,這裡的確是我剛剛數字寫反了…我修 改了一下並把你想要說的補充上去
*樓樓上
*知道 (自動選字QQ
推這篇對 REST 描述得滿清楚
推
我剛剛沒有注意 GitHub 原文那段,原來 GitHub in some
places 沒權限時回404,我個人本來以為應該優先回 403
比較合理 (無論背後資源是否存在,都回 403 並不會讓 u
nauthorized user 知道資源到底在不在),推測也許考量
觀點是:看到 403,hacker 會覺得背後資源有可能存在,
而繼續找其他方法突破 auth;但看到 404 很大機率是資源
真的不存在,effort 取捨下會放棄 hack 這個資源,避免
hack 半天一場空
無論「資源是否存在都回 403」 這件事情卡到的是有公開倉庫: 存在的公開倉庫有權限 200 存在的公開倉庫沒權限 200 存在的私有倉庫有權限 200 存在的私有倉庫沒權限 403 -> 被猜出 不存在的公開倉庫 404 -> 合理 不存在的公開倉庫 403 -> 不合理
推
謝謝原po的列舉解說,以 Github 的 case 來說確實卡到了
公開倉庫 和私有倉庫 是同樣的 path pattern,無法在判
斷倉庫是否存在前就先以 403 阻擋
說得很清楚,推
GitHub不要說REST了,就連網頁介面照樣丟404 XD
推
推這篇,寫得很清楚
原文搞錯了。重點不在查詢資源存在不存在。而是你認為Clie
nt的Request行為,是正常還是預期外的error。4xx開頭是 er
ror 。2xx開頭是 Info。
請參考RFC2616。
好了啦,你要扯國際規範我拿給你呀:
https://www.rfc-editor.org/rfc/rfc7231#section-6.3.1https://www.rfc-editor.org/rfc/rfc7231#section-6.3.5
The 404 (Not Found) status code indicates that the
origin server did not find acurrent 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 方式處理。
推
讚讚
推
推
nice nice
原文那2位版友是在指API回空資料應該要用200而非404吧?
就是對應到原po的"空無一人,並不是沒有清單"這項
/users/<USERNAME> 已經指定user卻找不到是種錯誤回404
/users/<USERNAME>/followers 沒有是一種正常情況回200
這個是萬年議題了...怎麼沒有人把204一起拉來參戰? 國外
都是200, 204, 404大亂鬥的
可是明明就有啊.204
原文在問的不是你這個找不到user的狀況吧 比較像是有
這個user但他沒有repo
原 po 只有說沒資料吧? /users/<USERNAME> 當 USERNAME
不在資料庫中,也是沒資料...
可能要釐清最原po的"沒資料",是指null,還是{}或[] ?
所以應該引導他去思考這件事情,而不是直接就說 404 或 200
的直接方案,這個從那篇的推文跟我這篇回文,我有將情境和
前提敘述出來的
404和403的部分其實兩個都可以,只要統一即可
讓存在但沒權限和不存在兩個狀態無法分辨即可
RFC 403的理由不一定要跟權限有關,而404也可以是故意隱藏
當然如果網站有公開的部分,統一成404比較合理
下面寫得不錯但是上面酸他們沒必要 他們只用一行字要怎
怎麼表達404不該用在[]
而且我看原標題也會覺得再問array為空 單一資源沒有的話
不太可能會想用200
這麼說吧,我看標題也會這麼認為,而且也同意這樣的狀況是
200 並回傳空值,但是看到文章內容,會提到 404 通常是與 R
EST 風格的這種資源不存在混淆(不論是發文者或是他看到這
樣實作的那個人)。
推文的可以選擇回文,也可以選擇推多行文字。直接用一行字
不負責任地表達又說可以 fire 人,還真不知道是我比較酸還
是他們比較酸?
推
推
推
原文拿Restful慣例(非國際標準),來戰國際標準。搞錯優先
權啦。
你是不是搞錯什麼了?你所說的國際標準考 慮到 REST 的使用,在 2014 年增修了內容 ,然後你一直說他增添的內容不符合國際標 準,大叔你是在哈囉?
https://i.imgur.com/r3WxHVV.png
不要只是噓文啊,拿你的國際標準寫篇文反 駁一下呀。我先跟你說在 RFC 7231 的第二 章就引用 [REST] 添加了資源(resource) 和表現層(Representations)的敘述。 拿出點證據來嘛!當大家沒看過文件?「說 話科學點,是身為工程師最基本的吧?」我 記得這好像是你說的?
推
倒是講到個點了,之前就想回標準是方便大家對齊用的,不
是權威鐵律,如果自己用標準感覺不方便可以不用符合,如
果大家都照標準走都覺得不方便也可以修
看到修文講到回一下 (飄走)
像是 Meta 家的就沒有很依照這篇提的 REST 風格(即使他們
宣稱是 REST API)
推 詳細
我覺得其實拿 RFC 2616 的敘述來佐證 API 設計很奇怪,他
當下主要目的就是設計給 hypermedia 資源的存取,只是後來
有些人決定也沿用這個來當 API 的協定當然現在就漸漸變成
常見的做法。就是因為後來才借用當然就需要一個 adapter
雖然不一定要是 rest 但不考慮中間這層直接去引用 http 的
敘述我是覺得一定會因為文件資源跟資訊的目的不同而對不上
上面並不是拿 RFC 2616 來佐證設計,而是 拿修正後的 RFC 723X 來說明 REST 風格的 合理性。 在 RFC 2616 還可以看到 URL 和 URN 的描 述,在 RFC 723X 就幾乎回歸到更為抽象的 URI 上了,更加強調「資源」的抽象概念。 你所謂中間那層的 adapater 其實就是文件 中對於 representation 的描述,而這也是 REST 風格的一部分: 「一個 URI 對應一種資源」 不論今天這個資源是一張圖片、一段文字、 一個頁面,都對應成一個 URI來表示。你要 提供資料庫中的使用者資訊、文章資訊,當 然也是可以,轉化成一個資源並對應,而在 目前多會以方便解析的結構化 JSON/XML 格 式表示這個資源。 另外必須補充一下,現代的客戶端並不是只 有網頁瀏覽器,如果都以瀏覽器的角度去看 的話,就很容易會因為你說的這個差異混淆 …
RESTful的精神就是回歸hypermedia,而不是用cgi的角度在看
不管背後是個File system還是Web framework,URI呈現出來的
就是資源、就跟一個網址對應一個網頁都一樣
反過來說不把URI當資源而是API端點的話,根本不用分path
像一般RPC把要做什麼也都放在參數不是更單純不會有404?
就是在Web API多數分path有分GET、POST,有的時候用4xx有時
候又用body內自定義code,沒一個原則,才會有人提RESTful
用本來就存在、實作也大致符合標準的HTTP來當這原則
我的意思就是怎麼樣都應該拿後期的 RFC 而不是 2616
也不是說一定要拿 RFC 但不能直接套用 2616 (回應科技博
正是因為是不是從瀏覽器出發的這個差異所以看舊的 RFC 的
時候要意識到當初他的設計不能用現代的方式自行解讀
這篇才是正解,回200與204都是積非成是
我覺得MT是最被看破手腳的 大概可以想成他其他話題
很嗆可能也是用類似的一知半解就不知道在嗆什麼……
推
5
4xx狀態表示你的請求本身有誤 例如404表示該資源不存在,(null)而不是空值(empty) 既然你的API本身存在,請求格式也正確 那麼如果結果為空值,該回傳2xx狀態 通常4xx都是來自於錯誤的客戶端請求2
個人拙見 鞭請小力 結論來說 原po的問題 我覺得應該是200 我的觀點偏向404屬於 該api路由、頁面不存在 github來說14
其實這都只是參考設計 怎樣處理都行 前端能接的起來就好 我個人則是傾向200或204 原因沒有什麼84
這篇就不以引述的方式回覆了,因為算是對 後續其他人不論在推文中或是回文中的內容 回覆,另外也是針對我自己在前一篇文章中 沒有提到的部分進行說明。 (1) 敘述問題與回答問題13
雖然我不是微軟派的,但是不得不說他們文件寫得真是認真 好入手,廣度,深度也都有一定程度的水準 --- (感謝ssccg提醒,我更正一下內容跟context56
首Po我看有些是狀態碼200,空data 但有些又是做404,然後回個message 數據不存在之類的 這哪一種做法比較好? --
爆
Re: [問卦]算命真能像了凡四訓裡說的那麼仔細正確?有鑑於過去的斗數推廣文章,都有抽選推文ID參與論命活動: 比如今年一月的文章,早已抽選出部分版友參與公益論命,我也寄了站內信個別通知。本 篇也會延續此傳統,邀請版友免費論命,或是參與我在斗數課程上的實習路人論命活動, 對此活動有興趣者,請務必參考與留意本文章最後面的細則。爆
Re: [問卦] 男森射精只能爽一下是不是很可悲?想認真回答一下 男人為什麼不能連續高潮呢? 偏要有個不反應期(聖人模式) 很不公平對吧! 其實這是一種應對方式爆
Re: [問卦] 伊莉論壇是不是站主早就放推了阿因為伊莉那個網站系統是很早期的康盛創想開發的 Discuz!, 是遠在賣給騰訊之前非常早期的商業授權版本, 騰訊接手後的 Discuz! X 3.4 v20191202 才會換成 HTML5。 要從古早時期的商業授權版本換到近代的 Discuz! X 是有難度的, 特別是有些站架起來以後還會對原始碼做一些魔改導致升級困難。爆
[問卦] 台灣真的有在做資源回收嗎?小弟我是很守規矩的R 雖然沒有分類到寶特瓶鐵罐鋁罐那麼細 但是基本的資源回收還是慧芬的 至少是垃圾一類、資源回收一類 有次在公司分類垃圾要下班79
[閒聊] 看著高雄的資源大家會覺得不平衡嗎?如題 最近晚上竹科附近老是聞到臭的空氣 每天上下班塞車塞的要死 卻也不見有什麼有效的改善建設 政策 明明新竹不管是產業產值、居民納稅金額24
[分享] 關於教育資源的差異原討論是本版這一篇: 文章代碼(AID): #1YQ0YCxT [請益] 關於在台東教書 : 推 maybetodo : 我從台北市非升學型學校調回高雄升學名校。就有非 04/27 09: 12 : → maybetodo : 常強烈的資源落感覺。在高雄10年了,學校的資源趕 04/27 09:20
Re: [問卦] 資源回收是玩真的玩假的?原本不確定,但近一年來可能變成假的(?) 我這邊台南,以前收垃圾是第一台一般垃圾壓縮車 第二台是開放車斗的資源回收車在收資源回收 可是最近變成多了第三台跟在後面 明明是壓縮車,可是上面掛了大大的紅布寫"資源回收車"16
Re: [分享] 關於教育資源的差異既然討論教育資源, 辦公室風氣:與人有關,只要有八卦女王,就免不了三姑六婆,所以不是教育資源相關 行政風氣:與校長領導風格有關,也不是教育資源相關 學生態度:與學生組成有關,又不是雙北沒有8+9,與教育資源無關 只討論資源的話,多數南漂的老師都會有感。