可以将语义信息放入REST API中的HTTP原因短语中吗？

例如，我可能希望返回资源的当前序列号，并且对版本化资源的HEAD请求做出409响应，但由于HEAD不允许，因此我可能不会在响应实体中提供它。另一个例子：假设由于版本冲突，对提交端点的POST请求失败。我可以用409响应，但有时我可能想另外通知客户它正在提交的事务已超出最大重试次数，并且进一步的尝试将不会成功。我可能会返回HTTP/1.1 409 Conflict/final，而不是在这种情况下只有HTTP/1.1 409 Conflict。我的问题是，这是可接受的做法吗？ HTTP 1.1 RFC没有为这个问题提供明确的答案。可以将语义信息放入REST API中的HTTP原因短语中吗？

我知道我可以把这些信息放在一个X-...的HTTP头中，或者以某种方式在响应实体中包含这些信息（额外的XML标签或JSON属性等）假设我不能或不想做所以如果我能帮助它。

来源

2014-11-04 Anton Tykhyy

原因词组很可爱，用于调试;但就是这样。它在HTTP/2中消失了，并且可能被中介和/或软件库丢失;不要依靠它被保存。

来源

2014-11-04 11:59:51

-1

HTTP响应的格式是

状态行= HTTP版本SP状态码SP原因短语CRLF

按照该规范，在此原因短语可以是定制。您可以添加您的版本的错误消息。请检查这里http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html。它提到

这里列出的短语的原因只是建议 - 它们可能会被本地等价物替换而不会影响协议。

来源

2014-11-04 10:19:46 shobhita

RFC是我第一次阅读的内容。我认为“本地等值”是指一个德国服务器说“404 Nicht Gefunden”而不是“404 Not Found”。目前还不清楚我是否可以在那里提供语义信息，或者这是否是一个好主意。 – 2014-11-04 10:33:16

请不要再引用RFC 2616。 – 2014-11-04 11:58:29

@JulianReschke真诚的问题：我们应该看什么而不是RFC 2616？（我在与OP相同的问题上登陆此页面，在我到达此处之前也阅读了RFC 2616）。 – 2015-12-29 15:05:39

可以将语义信息放入REST API中的HTTP原因短语中吗？

回答

相关问题