在HTTP頭或響應正文中留下錯誤消息？

我有一個暴露給iPhone和Android客戶端的REST服務。目前，我按照HTTP代碼200，400，401，403，404，409，500等在HTTP頭或響應正文中留下錯誤消息？

我的問題是在哪裏是把錯誤的原因/描述/原因推薦的地方嗎？對於REST API來說，在頭文件中總是有自定義Reason，這樣做會更有意義嗎？

< HTTP/1.1 400 Bad Request - Missing Required Parameters. 
< Date: Thu, 20 Dec 2012 01:09:06 GMT 
< Server: Apache/2.2.22 (Ubuntu) 
< Connection: close 
< Transfer-Encoding: chunked

還是更通過JSON有它在響應主體？

< HTTP/1.1 400 Bad Request 
< Date: Thu, 20 Dec 2012 01:09:06 GMT 
< Server: Apache/2.2.22 (Ubuntu) 
< Connection: close 
< Transfer-Encoding: chunked 
< Content-Type: application/json 
{ "error" : "Missing Required Parameters" }

來源

2012-12-20 James Cowhen

現今，這是一個常見的做法是添加自定義標題，例如「X-HTTP-錯誤 - 說明：缺少所需的參數」。 – andreszs

從400.x錯誤代碼的HTTP說明書引述：

的4XX類的狀態碼被用於在其中客戶端似乎出現了偏差的情況。除了響應HEAD請求外，服務器應該包含一個實體，其中包含對錯誤情況的說明，以及它是臨時還是永久性條件。這些狀態碼適用於任何請求方法。用戶代理SHOULD 向用戶顯示任何包含的實體。

最好的做法是將錯誤消息作爲實體包含在HTTP響應的主體中 - 無論是JSON，純文本，格式化的HTML還是其他可能需要使用的格式。

來源

2012-12-20 01:33:36 Perception

這並沒有回答這個問題：將錯誤消息放在響應頭或響應體中是否更好？ –

最好是在正文中有錯誤的詳細信息。此外，許多（大多數/幾乎所有的，例如WSGI）服務器和客戶端不支持更改錯誤代碼的名稱 - 將它們視爲固定對（例如400總是「錯誤請求」而不是「錯誤請求 - 您忘記指定用戶ID「）。即使它們不會中斷，它們也不會在意特定錯誤代碼的特殊名稱。

來源

2012-12-20 01:31:30 Tadeck

我總是一舉兩得。我通常將狀態消息設置爲前端可以以友好的方式顯示給用戶的內容，例如「409 - 無法添加新用戶，他們已經存在」。

然後，我將錯誤條件的詳細信息作爲JSON包含在主體中，以便UI開發人員可以嘗試對做什麼做出明智的選擇。

{ 
    "status": 409, 
    "message": "The user <username> was already added on <when> by <who> and given the user id 12345.", 
    "errors": { 
    "id": 12345 
    } 
}

來源

2017-08-17 17:59:34

在HTTP頭或響應正文中留下錯誤消息？

回答

相關問題