REST Web服务：响应状态为4XX时可接受的HTTP响应内容类型（客户端错误） [英] REST Web Service: Acceptable HTTP response content-type when responding with status 4XX (Client Error)

问题描述

我一直无法在HTTP规范中找到任何文档来管理生成HTTP响应是否可接受包括人类可读错误消息（例如content-type：text / plain）如果HTTP客户端生效无效HTTP请求，并指定了一个使用accept标头限制可接受的响应内容类型的请求标头。

I have been unable to find any documentation in the HTTP specifications that govern whether it is acceptable to generate a HTTP response include a human readable error message (e.g. content-type: text/plain) if an HTTP client has made an invalid HTTP request, and specified a request header that limits the acceptable response content types using an accept header.

想象一下，一个REST Web服务客户端向http：发出无效的GET请求// myhost / validpath？illegalRequestParameter = rubbish，包括请求标题Accept：application / xml或Accept：application / vnd.ms-excel。

Imagine a REST web service client issuing an invalid GET request to "http://myhost/validpath?illegalRequestParameter=rubbish", and including a request header "Accept: application/xml" or "Accept: application/vnd.ms-excel".

服务器将使用4XX系列中的HTTP状态代码进行响应（在本例中为400 Bad Request）。但是，该服务如何能够向客户传达有关错误原因的信息？

The server would respond with an HTTP status code in the 4XX series ("400 Bad Request", in this case). But how would the service be able to convey information to the client about the cause of the error?

我看到以下选项：

1. 在HTTP响应内容中创建纯文本错误消息。
   设置响应标头Content-type：text / plain，并在响应内容中包含描述性错误消息。但是，这会破坏HTTP客户端的接受限制。

1. Create a plaintext error message in the HTTP response content. Set response header "Content-type: text/plain" and include a descriptive error message in the response content. This would, however, break the HTTP client's "Accept" restriction.

不包含HTTP响应内容。
这显然是有效的，但对于只知道发生客户端错误但无法知道原因（并在客户端日志文件中报告原因）的客户端没有太大帮助。

Don't include a HTTP response content. This is clearly valid, but not very helpful to the client that just knows that a "Client Error" occurred but has no way of knowing why (and reporting the reason in a client log file).

尝试将错误消息强制转换为可接受的MIME类型。
这很少可能。即使错误消息可以构造为有效的application / xml类型，也可能会破坏Web服务合同（例如XML Schema一致性）。

Try to coerce an error message into an "Accept'able" MIME type. This is rarely possible. Even if the error message could be constructed as a valid application/xml type, it would likely break a web service contract (e.g. XML Schema conformance).

我的问题是：上述情况是否受现有HTTP规范/标准的约束？

参考文献：

1. HTTP状态码定义： http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html


2. HTTP标头字段定义 http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

1. HTTP Status Code Definitions: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
2. HTTP Header Field Definitions http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

推荐答案

如果接受标头是'application / xml'，那么您应该将错误消息作为XML。它会破坏客户端，但无关紧要，客户端无法获取他们请求的信息。至少客户端能够解析错误消息...

If the accept header is 'application/xml', then you should return your error message as xml. It will break the client, but that doesn't matter, the client isn't getting the information they requested anyway. At least the client is able to parse the error message...

这篇关于REST Web服务：响应状态为4XX时可接受的HTTP响应内容类型（客户端错误）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！