发布条件检查http状态答案

【问题标题】：Post condition check http status发布条件检查http状态
【发布时间】：2016-05-31 02:36:29
【问题描述】：

使用以下 API：

feed?url=XXX

对参数url执行的验证：

3.应该返回什么状态错误？

与验证 2. 不同，如果不获取数据并尝试解析它，则无法检查 3.，因此是原始用户数据 无法直接验证。

我在考虑422 Unprocessable Entity，因为它与验证有关，即使不是直接数据（url）而是该数据的引用（url 的内容）。

你的意见是什么？

【问题讨论】：

【解决方案1】：

422 不适用于#2 和#3。与服务器理解Content-Type header有关，但无法解释HTTP请求体中的实际内容。

我认为您可以提出502 Bad Gateway 在这里合适的论点。这有点奇怪，因为问题是 both 用户错误（传入的 url 参数，所以是 4xx 代码），而且它也发生在服务器上，特别是原始服务器（这很有意义5xx，特别是 502）。

但是，如果在这种情况下，您严格认为这是客户端导致的问题（url 中的错误输入）而不是服务器端，那么我会说没有足够具体的错误代码，您可能应该所有人都坚持400。

也许......也许你可以提出 409 可能在这里工作的论点。 409 可用于以下情况：

通常，“其他资源”存在于同一系统中，但我不明白为什么外部 Atom 提要也不能被视为冲突。

因为如果外部服务器上的 Atom 提要是“固定的”，那么用户发出的原始 HTTP 请求现在可以工作。所以409 在这里是合适的。

【讨论】：

关于422 我同意查询参数不是entity 的一部分，因此可能很难返回Unprocessable Entity。但我真的不认为409 Conflict 是更好的选择（从我在这里读到的tools.ietf.org/html/rfc7231#page-60）。
我对 409 的体验以及它的使用方式源于它在 WebDAV（HTTP 扩展）中的使用。它的应用方式几乎普遍意味着“请求没有错，如果在不同资源的状态发生变化后再次发送它可能会成功”。这也绝对是我从 HTTP 扩展中解释 409 的方式，即使它在那里更笼统和神秘。