分頁結果上的REST狀態代碼204

我正在爲基於YUI的客戶端的分頁數據檢索設計一個REST API。其餘的URL看起來像這樣的一個GET請求：分頁結果上的REST狀態代碼204

/app/catalog/data?startIndex=<int>&results=<int>&sort=<sting>&dir=<string>

所有參數都是可選的，即如果沒有給定參數，從數據庫的所有數據將被傾倒。現在說數據庫中只有1000條記錄。繼reqeust由：

/app/catalog/data?startIndex=1100&results=25

我應該返回什麼狀態代碼，如果從數據庫中分頁結果仍然爲空，雖然要求是罰款？我無法決定這是204還是404。

生成的媒體類型是JSON和CSV。

來源

2012-07-09 Michael-O

我會說204是最合適的。要求是成功的，只是沒有結果。

10.2.5 204 No Content 

The server has fulfilled the request but does not need to return an entity-body, and might want to return updated metainformation.

聽起來很像這種情況。

來源

2012-07-09 20:01:41

在這種情況下，「404」會有什麼區別？無效的排序列將是一個'錯誤的請求'。 – 2012-07-09 20:08:25

@ Michael-O無效的排序列將是一個「錯誤的請求」，因爲它只是一個無效的選項。然而，在這種情況下，這是一個完全有效的請求，它恰好沒有任何返回值。此外，將來，請求可能會返回一個值，而無效排序列永遠不會如此。 – 2012-07-09 23:20:10

所以，我會堅持204這似乎是在這種情況下最好的解決方案。謝謝。 – 2012-07-10 11:19:19

你通常會返回什麼格式的結果？我傾向於使這204甚至200返回一個空的列表。

來源

2012-07-09 20:00:08

JSON有效負載與結果以及YUI的元數據。如果有要求，它也可能返回'text/csv'。 – 2012-07-09 20:04:03

如果元數據可以告訴人類發生了什麼事情（請求的頁面/切片是空的），我肯定會返回200空數據有效載荷。 – 2012-07-09 20:07:39

不，它不能。這僅適用於M2M。人應該使用基於YUI的界面。 – 2012-07-09 20:09:32

我不能決定這是204還是404。

都沒有。只需返回空白結果200（空XML文檔或JSON數組，無論您使用什麼）。通常我使用帶有分頁視圖的REST服務，以及結果頁面，並返回總記錄數。這將幫助客戶意識到這個錯誤。但從技術上講，這沒有錯。

使用204爲DELETE操作（確實沒有內容可以返回）和PUT。

BTW（粗體礦）：

如果沒有給出參數，從DB的所有數據都將被轉儲

相信，你不想這樣做...

來源

2012-07-09 20:02:06

根據RFC 204在GET上很好。爲什麼我應該返回200，如果我只有204這樣的完美狀態代碼？數據量不是很大，除了我的情況下輸出格式也可以是CSV。 – 2012-07-09 20:07:13

來自httpbis，這是IETF工作組正在進行的工作，以清除HTTP中的一些歧義：「204響應允許服務器指示操作已成功應用於目標資源，同時暗示用戶代理不應該從當前的「文檔視圖」（如果有的話）中移走。「它不打算將視圖更改爲空集;它的目的是在不改變視圖的情況下完成工作。見http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-19#section-7.2.5 – fumanchu 2012-07-10 05:57:40

即將說出同樣的事情，即「無論如何，只需返回200結果爲空」。這是正確的做法。請參閱https://stackoverflow.com/a/38659868/325521，瞭解爲什麼'204'不適用於每個RFC 7231規範。 '404'肯定是錯誤的，因爲'404'是找不到資源的（即缺少資源，不存在但爲空資源，這就是這種情況） – Shiva 2017-10-21 00:29:39

分頁結果上的REST狀態代碼204

回答

相關問題