在HTTP警告标题中放置详细的REST错误消息，好/坏主意？ [英] Putting detailed REST error message in HTTP Warning header, good/bad idea?

问题描述

如果出现问题，我们正在使用HTTP状态代码作为响应代码开发标准REST服务。 （例如，无效的用户输入会向客户端返回400 Bad Request）

We are developing a standard REST service using HTTP status codes as its response code if something went wrong. (e.g. invalid user input would return "400 Bad Request" to the client)

但是，我们认为更详细的错误消息对客户端有用。 （例如，无效输入错误是由于X是无法识别的参数名称）

However, we felt that a more detailed error message would be useful for the client. (e.g. the invalid input error is due to X being a unrecognized parameter name)

我们希望尽可能忠实于HTTP规范，因此在研究了规范之后在 RFC2616 中，我们正在考虑将详细的错误消息放在HTTP标头中，特别是在< a href =http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.46> HTTP标头警告字段。它在RFC上说：

We would like to be as faithful to the HTTP specs as possible, so after studying the specification in the RFC2616, we are thinking of putting the detailed error message in the HTTP Headers, specifically on the HTTP header warning field. It said on the RFC that:

警告通用标头字段用于携带有关状态或转换的其他信息消息中可能未反映的消息。此信息通常用于警告缓存操作或应用于消息实体主体的转换可能缺乏语义透明度。

The Warning general-header field is used to carry additional information about the status or transformation of a message which might not be reflected in the message. This information is typically used to warn about a possible lack of semantic transparency from caching operations or transformations applied to the entity body of the message.

对于其他警告（例如REST错误消息）使用此标头似乎没有限制，即使是根据此标头的初始意图与缓存警告无关的警告也是如此。我们喜欢语义，我们计划使用299警告代码，这似乎非常适合该法案：

There seems to be no restriction on using this header for other warnings (such as REST error message), even those that are unrelated with the cache warnings as per the original intention of this header. We like the semantic, and we planned to use the 299 warning code, which seems to fit the bill quite nicely:

299杂项持续警告警告文本可以包含要呈现给人类用户或记录的任意信息。接收此警告的系统不得采取任何自动操作。

299 Miscellaneous persistent warning The warning text MAY include arbitrary information to be presented to a human user, or logged. A system receiving this warning MUST NOT take any automated action.

因此，如果此问题顶部显示无效的输入错误案例，我们正在考虑将REST错误消息如下例所示：

So, given the invalid input error case presented on the top of this question, we're thinking of putting our REST error message like the following example:

HTTP/1.1 400 Bad Request
Warning: 299 ServiceName "Invalid input error: X is unrecognized parameter name."

这是一个好主意/做法吗？我们还发现一些服务在X-Warning标题中详述了此消息，但这似乎不是标准的。我们想知道stackoverflow REST人群的蜂巢智慧会对此有何看法。在REST响应中传递详细的错误消息是否还有更好/标准化的做法？

Is this a good idea/practice? We also found that some services detailed this message in X-Warning header, but this seems to be not standard. We are wondering what would the hive wisdom of stackoverflow REST crowd think about this. Is there also any better/standardized practice for passing out detailed error messaging in REST responses?

推荐答案

为什么不改变原因短语？这就是它的用途。 错误请求文本只是默认值。如果要包含更多信息，请使用响应正文。 HTTP规范说你应该包含一个包含错误详情的响应正文。

Why not just change the reason phrase? That's what it is there for. The "Bad Request" text is just the default. If you want to include more information then use the response body. The HTTP spec says you SHOULD include a response body with details of an error.

UPDATE

根据最近阅读的RFC 7231和相关材料，似乎更改原因短语的唯一正当理由是本地化文本，而不是提供更具体的含义。对不起。

Based on a more recent reading of RFC 7231 and related material, it appears the only valid reason for changing the reason phrase is to localize the text, not to provide a more specific meaning. Sorry about that.

这篇关于在HTTP警告标题中放置详细的REST错误消息，好/坏主意？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！