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

我正在努力將REST API從始終響應STATUS: 200 OK中移出，該STATUS: 200 OK包含返回的JSON中的error密鑰，並嘗試使用正確的狀態代碼在出現問題時。客戶端的HTTP狀態代碼已過期

到目前爲止，我已經感動我的服務器的大部分地區移交給適當的狀態碼200, 201, 400, 401, 403, 404, 500, 501, and 503

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

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

這是我的第一個REST API，它工作的很好，我只是試圖將其轉換爲以下最佳實踐。所以我有點驚慌。

TLDR;

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

2017-02-14 Hobbyist

你能詳細解釋一下你的意思是「過時嗎？」這聽起來像是你想用瀏覽器通知客戶太舊以至於不支持與HTTP無關的特定功能。 – DaSourcerer

@DaSourcerer在我的問題的底部，我說我的客戶是移動設備，當客戶端「過期」時，我的意思是應用程序版本。因此，如果一箇舊的應用程序版本從'/ v2/foo/ba'請求數據，並且它被卡在'/ v1'上，它應該告訴客戶端它已經過時，並且必須更新以訪問'/ v2'上的資源。 – Hobbyist

感謝您的滿足，這並不完全清楚:) – DaSourcerer

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

代碼426受制於RFC 7231, section 6.5.15。該代碼讓客戶知道用於訪問資源的[http]協議版本太舊而無法完成請求。這兩個代碼在這裏都不適用。

有了一點從this chart幫助，我想兩個代碼是充足的位置：

就個人而言，我會去與400你可能也想看看RFC 7807傳輸API錯誤的標準方法。

2017-02-14 12:30:57 DaSourcerer

喜雕塑家...如果你想堅持到正式的RFC發佈，那麼你應該檢查IETF網站（互聯網工程任務組）：

不知道哪些文件，但對於實例HTTP/1.1是RFC2616的一部分，但正如我在2014年發現的那樣，它被多個RFC（7230-7237）取代。

提到的狀態426表明：

「發送一個426（需要升級）響應必須發送一個升級頭字段以指示可接受的協議，以遞減的優先級順序

的服務器。

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

https://tools.ietf.org/html/rfc7230#section-6.7 - > 57頁左右，你可以找到整個描述:-) 「

請看看這些文件，以決定哪些錯誤代碼還給:-)

我希望這可以澄清你的查詢。祝今天好運！

2017-02-14 11:58:27

相關的是狀態碼註冊表，位於http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml –

非常好的鏈接:-)確切地說，狀態代碼來自IETF完成的RFC，這只是對IANA的一個很好的概述。 –

確切準確：關於狀態代碼的RFC規範（RFC 7231）將註冊表功能委託給IANA。所以這不是一個「概述」 - 它確實是正式註冊的狀態碼列表。 –

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

2017-02-14 12:29:55

回答