400 vs 422響應POST引用一個未知的實體

Question

我想弄清楚什麼是正確的狀態代碼返回不同的場景與我正在工作的「休息般的」API。

這個例子是從another question about syntax type問題中借用的，但是我的問題假設了整個有效的語法。

比方說，我有一個端點，允許在JSON格式POST'ing購買。它看起來像這樣：

{ 
    "account_number": 45645511, 
    "upc": "00490000486", 
    "price": 1.00, 
    "tax": 0.08 
} 

什麼是適當的狀態代碼，如果：

• 賬號不存在
• 的帳戶被關閉或確定的
• 帳戶是不正確的種類賬戶

這些都是牢固的業務層面問題，可以防止「處理」但是，一個場景涉及的東西，在一個GET將是一個404.

請注意帳號不在URL中，所以是404誤導？

Answer 1

讓我們一次拿這些。這些代碼中的每一個都是向您的客戶端發出的信號，表明服務器運行正常，並且在請求成功執行之前必須對其進行更改。

• HTTP 400

請求不能被服務器由於語法錯誤理解。客戶端不應該在沒有修改的情況下重複請求。

400通常指示語法錯誤;作爲用戶，我應該在再次嘗試之前查看請求的結構。

• HTTP 404

服務器沒有找到任何匹配的請求URI。沒有跡象表明病情是暫時的還是永久性的。如果服務器通過某種內部可配置機制知道舊資源永久不可用並且沒有轉發地址，則應使用410（Gone）狀態碼。當服務器不希望揭示請求被拒絕的原因時，或者沒有其他響應適用時，通常使用此狀態碼。

404是當Web服務器無法將url路徑與任何內容匹配時使用的標準代碼。作爲客戶端，我應該在再次嘗試之前查看請求的URL。

• HTTP 422

的422（無法處理的實體）狀態代碼表示的服務器理解的請求實體（因此一個415（不支持的媒體類型）狀態代碼是不適當的）的內容類型，和請求實體的語法是正確的（因此400（錯誤請求）狀態代碼是不合適的），但無法處理包含的指令。例如，如果XML請求體包含格式正確（即，語法正確）但語義錯誤的XML指令，則可能會出現此錯誤情況。

422通常用於內容違規。作爲用戶，我應該在再次嘗試之前查看我的請求的內容。

現在在你的情況下，帳號是一個識別號碼，但不包含在URL中。 404會告訴你的用戶URL是錯誤的，而不是有效載荷。換句話說，假設您的網址是：

http://www.myservice.net/endpoint 

404將指示我沒有服務在/端點存在，而不是沒有帳號。無論我提交什麼內容，服務器都不會處理我的請求。我應該做的修復將是在URL中查找錯誤，而不是數據有效載荷。所以對我來說422會指向正確的方向，除非你開始在URL中包含帳號。

最終，這些都是設計偏好，只要確保將它們清楚地傳達給用戶即可。

Answer 2

事實上，在這種情況下，404聽起來不錯。

Answer 3

我想說你的情況下422是足夠的，但如果它與你的其他API一致的話，400並不壞。當客戶端出現問題時，使用400作爲傘形錯誤代碼是一種常見的約定，但是錯誤不適合特定的錯誤代碼，或者您不想使用太多的錯誤代碼。

如果POST有效負載出現問題，404肯定是錯誤的。

Answer 4

如果您認爲這些帳戶屬於資源狀態（儘管是間接的），那麼您也可以考慮409，因爲該狀態與請求的語義衝突。

但是，422通過Ruby on Rails和Dropwizard越來越受歡迎，它用於指示正​​文中的非語法問題。這種增長趨勢對於使用API​​的開發者來說是一個強烈的信號，他們需要排除語法並專注於主體。開發人員時間通常是您的客戶所承受的最大成本，因此通過引導開發人員的注意力，您可以讓他們感到滿意。

因此，409是一個可能的答案，雖然相當新穎，422是更傳統的方法，但顯然RoR和DropWizard都相當新，所以這些約定可以說是變化很快！

Answer 5

案例1：帳號不存在。 這是404的標準案例。

案例2：帳戶已關閉。 如果在關閉帳戶時保留帳戶的詳細信息，這與邏輯有關。 如果您在帳戶關閉時不保留帳戶詳細信息，則可以給404。 如果您在關閉帳戶後保留帳戶詳細信息，您必須對其進行標記（如提高某個標記）（或您擁有的任何邏輯）。在這種情況下，狀態代碼400將顯示正確的消息，說明爲什麼它失敗並可能需要補救。

案例3：帳戶識別不是正確的帳戶類型。 403，因爲賬戶沒有被授權完成任何購買對我來說是有意義的。如果沒有授權賬戶這樣的概念，400將會有解釋性信息。但在這種情況下，我會堅持要用403。