REST API中的HTTP狀態代碼，用於使用GET查詢“尚未准備好，稍后再試”資源？

Question

首先，我讀了一些相關的帖子：

• REST API中用於“尚未准備好，稍后再試”的最佳HTTP狀態代碼？ 這是關於GET項目
• 在響應HTTP GET時返回202“Accepted”是錯誤的嗎？ 這是關於GET項目
• 資源的HTTP狀態代碼尚不可用它是關於POST的
• 正在進行的HTTP狀態代碼？ 這是關於GET，但沒有明確的答案。

但我仍然認為我應該在這里提出我的問題和想法。 REST API中的HTTP狀態代碼應該是什么？使用GET到QUERY“未准備好，稍后再試”資源？ 例如，客戶端嘗試通過對此URL進行HTTP GET來查詢將來發生的所有本地新聞（！）： http ： //example.com/news ？city = chicago＆ date = 2099-12-31那么服務器應該回復什么？

這些是我考慮的http狀態代碼，它們的rfc定義以及為什么我不完全滿意：

• 3xx重定向。 注釋 ：不是一個選項，因為沒有其他鏈接可以重定向到。

• 503服務不可用：由於服務器臨時過載或維護，服務器當前無法處理請求。 這意味着這是一個暫時的條件，經過一段時間的延遲后會得到緩解。 如果已知，則可以在Retry-After報頭中指示延遲的長度。 注釋 ：需要重試行為，但從語義上講，情況根本不是服務器的錯誤，因此所有5xx看起來都很奇怪。

• 4xx客戶端錯誤。 評論 ：看起來很有希望 見下文。

• 413請求實體太大：服務器拒絕處理請求，因為請求實體大於服務器願意或能夠處理的請求實體。 ...如果條件是臨時的，服務器應該包括一個Retry-After頭字段，以指示它是臨時的，以及客戶端可以再次嘗試的時間。 注釋 ：需要重試行為，但“實體太大”部分有些誤導。

• 417期望失敗：此服務器無法滿足Expect請求標頭字段（請參閱第14.20節）中給出的期望。 注釋 ：所以它應該是由Expect請求標頭引起的，不適用於我的情況。

• 406 Not Acceptable：資源...根據請求中發送的accept頭不可接受。 注釋 ：所以它是由Accept request-header引起的，不適用於我的情況。

• 409沖突：由於與資源的當前狀態發生沖突，無法完成請求。 此代碼僅在預期用戶可能能夠解決沖突並重新提交請求的情況下才允許。 ...響應PUT請求最有可能發生沖突。 評論 ：這個很接近。 雖然我的情況不是關於PUT，實際上並不是由沖突造成的。

• 404 Not Found：服務器未找到與Request-URI匹配的任何內容。 評論 ：從技術上講，我的網址路徑（ http://example.com/news ）存在，它是導致問題的參數。 在這種情況下，返回空集合而不是404，可能更合適。

• 403 Forbidden：服務器理解請求，但拒絕履行請求。 授權無效，請求不應重復。 評論 ：通常這應該用於任何受限制的資源？

• 400錯誤請求：由於語法格式錯誤，服務器無法理解請求。 客戶端不應該在沒有修改的情況下重復請求。 評論 ：在我的案例中並非如此。 我的服務器理解請求，它的語法很好，只有意思不好。

• 2xx成功。 評論 ：如果4xx不起作用，2xx怎么樣？ 見下文。

• 200好的。 評論 ：很好。 那么我應該在響應體中包含什么呢？ null或[]或{}或{“date”：“2099-12-31”，“content_list”：null}或者......哪一個更直觀？ 另一方面，我更喜歡一種方法，以明確區分未成年人“未來新聞”錯誤與更常​​見的“所有查詢標准都很好，這一天沒有新聞”的情況。

• 202 Accepted：已接受請求進行處理，但處理尚未完成。 該請求最終可能會或可能不會被采取行動。 注釋 ：假設我們可以在GET請求中使用202，則可以接受。 然后參考200評論。

• 204 No Content：服務器已完成請求，但不需要返回實體。 注釋 ：假設我們可以在GET請求中使用204，則可以接受。 只是不知道這是否優於202或200。

• 更多關於2xx： 評論 ：我認為所有2xx響應都可能在某處緩存。 但在我的情況下，如果我為“明天的新聞”返回一個空體，我不希望它被緩存。 好的，明確指定“無緩存”標題應該有所幫助。

你的意見？

Answer 1

使用404。

您對它的反對意見是基於對URI的普遍理解，因為它不包括查詢字符串。 “因為我有多個映射到同一個處理程序的URI，”邏輯說，“我的資源確實存在並且只是通過查詢字符串args進行參數化。”

這是不正確的。 正如URI規范本身在第3.3節（強調我的）中所述，

“路徑組件包含通常以分層形式組織的數據，與非分層查詢組件 （第3.4節） 中的數據一起用於標識URI方案和命名權限（如果有）范圍內的資源。 “

資源由URI標識，對absolute-URI的任何部分的任何更改都標識單獨的資源。 每天一次向每個人發推，直到他們告訴你停止。 因此， 404是完美的匹配：“404（未找到）狀態代碼表示源服務器沒有找到目標資源的當前表示，或者不願意透露存在該目標資源。”

Answer 2

您正在檢索當天的新聞，這是有效的一天，沒有任何新聞。 空體的200響應，或基於介質類型的任何有意義的響應似乎是合乎邏輯的。 這取決於您與客戶決定的媒體類型。

如果日期格式錯誤（你要求11月45日，或者要求一個不存在的城市），404會更有意義。）

另外，URL格式會更好，格式為http://example.com/news/chicago/2099-12-31，因為這是您要檢索的特定資源。 這種格式可以使像404這樣的東西更清晰。