HTTP 200或404爲空列表？

我知道這是一個相當普遍的問題，但我還沒有找到滿足我的答案。HTTP 200或404爲空列表？

我一直在使用Django rest框架一段時間了，但除了給出的例子外，這大部分都是不相關的。它的默認行爲是在訪問具有空項目列表的路由時，返回帶有空列表資源的HTTP 200。例如： - 如果我們有一個途徑，例如/articles/訪問的文章列表但它不包含項目，我們會得到像下面這樣的JSON響應：

{"count":0, "next":null, "previous":null, "items": []}

這是完全正常的。我們在/ articles /找到了我們正在尋找的資源，它恰好沒有任何項目。

如果我們訪問路線/articles/?page=1，我們得到完全相同的響應。

到目前爲止這麼好。現在我們嘗試訪問/articles/?page=2，並且響應代碼發生更改。現在得到一個404就好像資源找不到，並顯示錯誤消息說該頁面沒有結果。這與使用相同的情況？page = 1 ...

我對此行爲非常滿意，但今天我開始質疑此設計。 ?page=1與?page=2有什麼不同？而且，如何在發出HEAD請求時判斷請求是否「有效」？在包含任何結果的意義上有效。

這對於篩選列表來檢查某個字段的可用性（例如，向/users/?username=ted發出HEAD請求）時可能會有用。

200響應顯然意味着請求被理解並找到了項目。
404將意味着請求被理解，但被發現在該位置沒有物品/ URI（AFAIK查詢參數也URI的一部分）
如果請求不能被理解400將被返回用於語法錯誤，用於語義錯誤422。

這是一個很好的設計嗎？爲什麼大多數人似乎不同意它，它有什麼缺點？

來源

2015-05-13 Rubén Durá Tarí

恕我直言，200更好，因爲404不允許區分* no api部署*和*空列表*。 –

這在概念上是不是一樣？該位置沒有資源。客戶不應該（理論上）在適當的休息實施中擔心端點，所以差異應該不重要（理論上在適當的休息api下）。 –

我看到它的方式：'/ articles /'是所有文章的列表;即使它是空的，它仍然存在。而在大多數網站上，即使是空白列表也有第一頁，告訴你沒有結果。 –

我會去200，因爲資源是articles。雖然查詢ted在users同樣適用，users是資源，只要它在那裏，從我的角度來看，200是好的。如果您願意GETusers/ted如果名爲ted的用戶在過去（可能比用戶更適用於文章），那麼a 404會和410 (GONE)一樣好。

來源

2015-05-13 14:45:07 sschrass

當頁面2不存在時，/ articles /？page = 2會是什麼情況？遵循相同的邏輯，/ articles /存在，所以即使沒有項目，也應該返回200。我對嗎？我不同意這種設計，但正如我在原帖中所說的，我明白爲什麼有些人會同意這一點。我只是在這裏遵循不同的思路。 –

'/ articles /？page = 2'會導致一個包含空列表的200響應，因爲有文章，但第二頁沒有。 – sschrass

我用它認爲它像一個數據庫查詢，其中結果集是空的，但查詢語法上沒問題。 – sschrass

200僅表示請求已成功。與響應一起返回的信息取決於請求中使用的方法，例如： GET在響應中發送與請求的資源相對應的實體;

HEAD與請求資源對應的實體頭字段在沒有任何消息體的響應中發送;

發佈描述或包含操作結果的實體;

跟蹤由最終服務器收到的包含請求消息的實體。 404 - 服務器沒有找到任何與Request-URI相匹配的東西 - 在這種情況下，我認爲這意味着我們沒有找到文章將被列出的頁面。因此，它是200。 - 但也許理解什麼是返回並格式化0文章已被返回的消息。

來源

2015-05-13 15:03:38 WILLISPIN

因爲我們對一個空的page1沒問題，對一個空的page2沒有問題。

這是由用戶界面考慮（頁面1必須存在！）驅動的，但它決定響應代碼。

來源

2015-05-13 23:31:50 ZhongYu

HTTP 200或404爲空列表？

回答

相關問題