客戶端的HTTP狀態代碼已過期

Question

我正在努力使我的REST API遠離始終響應STATUS: 200 OK如果出現問題則返回JSON中的error鍵，並在出現問題時嘗試使用正確的狀態代碼。

到目前為止，我已將服務器的大多數部分移動到正確的狀態代碼200, 201, 400, 401, 403, 404, 500, 501, and 503

目前，我正在試圖找出拒絕過時訪問API調用的最佳方法。 目前我正在發送使用授權令牌編碼的客戶端版本。

我在使用狀態代碼426, and 412之間陷入困境。 426狀態代碼的標題看起來像我想要的用例，但描述讓我有點擔心。 412看起來如果我將我的版本從授權令牌移開並將其放在它自己的標題內是合適的。

這是我的第一個REST API，它運行良好，我只是想將其轉換為以下最佳實踐。 所以我有點難以置信。

TLDR;

• 我應該將我的版本控制移動到標題並使用狀態412
• 我應該使用狀態代碼426
• 是否有我在這里缺少的代碼我應該用來請求客戶端更新。

注意：我的客戶端不是Web瀏覽器。 這是一個移動設備。

Answer 1

讓我們快速瀏覽您提出的解決方案：狀態代碼412現在受RFC 7232第4.2節的授權。 如果所述RFC的第3節中描述的一個或多個前提條件阻止給定的請求完成，則它將在條件請求的上下文中使用。

代碼426受RFC 7231第6.5.15節的約束。 此代碼使客戶端知道用於訪問資源的[http]協議版本太舊而無法完成請求。 這兩個代碼都不適用於此處。

在這張圖表的幫助下，我認為這里有兩個代碼就足夠了：

• 代碼400 / 錯誤請求

  400有點模糊（故意如此），表明請求的一般問題。

• 代碼403 / 禁止

  這有點拉伸，因為此代碼表示授權問題。 但是，它本身並不與身份驗證相關聯，因此您應該沒問題。

就個人而言，我會選擇400.您可能還想看看RFC 7807的傳輸API錯誤的標准化方法。

Answer 2

Hei Hobbyist ...如果你想堅持官方RFC發布，那么你應該檢查IETF網站（Internet Engineering Task Force）：

https://tools.ietf.org/html/

不確定哪個文檔，但是例如HTTP / 1.1是RFC2616的一部分，但正如我在2014年發現的那樣，它被多個RFC（7230-7237）取代。

提到的狀態426顯示：

“發送426（需要升級）響應的服務器必須按優先級降序發送升級頭字段以指示可接受的協議。

服務器可以在任何其他響應中發送升級頭字段，以通告它實現對升級到列出的協議的支持，按照優先級降序的順序，適用於將來的請求。

https://tools.ietf.org/html/rfc7230#section-6.7 - >第57頁左右你可以找到完整的描述:-)“

請查看這些文檔以確定要將其返回的錯誤代碼:-)

我希望這能澄清你的疑問。 祝你今天愉快！

Answer 3

這將是一個4xx狀態代碼，但我不認為有一個特定於您的用例。 因此，400應該這樣做。 （您可以在正文中發送錯誤詳細信息，例如， 請參閱https://greenbytes.de/tech/webdav/rfc7807.html ）