在HTTP警告标题中放置详细的REST错误消息,好/坏主意？

Question

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

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

我们希望尽可能忠实于HTTP规范,因此在研究了RFC2616中的规范之后,我们考虑将详细的错误消息放在HTTP标头中,特别是在HTTP标头警告字段中.它在RFC上说:

Warning general-header字段用于携带有关消息的状态或转换的其他信息,这些信息可能未反映在消息中.此信息通常用于警告可能缺少来自缓存操作或应用于消息实体主体的转换的语义透明性.

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

299其他持久警告警告文本可能包含要呈现给人类用户或记录的任意信息.接收此警告的系统不得采取任何自动操作.

因此,鉴于此问题顶部显示的无效输入错误情况,我们正在考虑将REST错误消息添加如下示例:

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

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

Answer 1

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

UPDATE

根据最近阅读的RFC 7231和相关材料,似乎更改原因短语的唯一正当理由是本地化文本,而不是提供更具体的含义.对于那个很抱歉.