REST Web服務：響應狀態為4XX時可接受的HTTP響應內容類型（客戶端錯誤）

Question

我一直無法在HTTP規范中找到任何文檔來管理生成HTTP響應是否可接受包括人類可讀的錯誤消息（例如content-type：text / plain），如果HTTP客戶端發出了無效的HTTP請求，並指定了一個請求標頭，使用accept標頭限制可接受的響應內容類型。

想象一下，一個REST Web服務客戶端向“http：// myhost / validpath？illegalRequestParameter = rubbish”發出無效的GET請求，並包含一個請求標題“Accept：application / xml”或“Accept：application / vnd.ms-excel” 。

服務器將使用4XX系列中的HTTP狀態代碼進行響應（在本例中為“400 Bad Request”）。 但是，該服務如何能夠向客戶傳達有關錯誤原因的信息？

我看到以下選項：

1. 在HTTP響應內容中創建純文本錯誤消息。 設置響應標頭“Content-type：text / plain”，並在響應內容中包含描述性錯誤消息。 但是，這會破壞HTTP客戶端的“接受”限制。

2. 不要包含HTTP響應內容。 這顯然是有效的，但對於只知道發生“客戶端錯誤”但無法知道原因（並在客戶端日志文件中報告原因）的客戶端來說，這不是很有用。

3. 嘗試將錯誤消息強制轉換為“可接受”的MIME類型。 這很難實現。 即使錯誤消息可以構造為有效的application / xml類型，它也可能會破壞Web服務契約（例如XML Schema一致性）。

我的問題是：上述情況是否受現有HTTP規范/標准的約束？

參考文獻：

1. HTTP狀態碼定義： http ： //www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
2. HTTP標頭字段定義http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

Answer 1

如果accept標頭是'application / xml'，那么您應該將錯誤消息作為xml返回。 它會破壞客戶端，但無關緊要，客戶端無法獲取他們請求的信息。 至少客戶端能夠解析錯誤消息......