2016-05-30 86 views
1

使用下列API:帖子条件检查HTTP状态

  1. 如果缺少:

    feed?url=XXX 
    

    验证的参数url进行400 Bad Request

  2. 如果空/无效网址:422 Unprocessable Entity
  3. 如果URL没有指向有效的RSS/Atom feed:422 ??

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

不同于验证2.,就不可能检查3.没有获取数据并试图解析,所以原始用户数据不能直接验证。

我在想422 Unprocessable Entity,因为它即使不是直接的数据(url),但该数据的引用(url的内容)相关的验证。

您的意见是?

回答

0

422对于#2和#3是不合适的。它与理解Content-Type标题的服务器相关,但HTTP请求正文中的实际内容无法解释。

我想你可以在这里说明502 Bad Gateway是合适的。这有点奇怪,因为问题是用户错误(传入的url参数,所以4xx代码),但它也是发生在服务器上,特别是原始服务器(这是有意义的5xx,特别是502 )。

但是,如果在这种情况下,你严格考虑这是一个客户端造成的问题(在url中输入错误)而不是服务器端,那么我会说没有足够的具体错误代码,你应该可能只是坚持400所有人。

也许..也许你可以让409可能在这里工作的论点。在以下情况下可以使用409:

  1. HTTP请求存在没有什么特别的错误。
  2. 但是另一个资源的状态导致请求失败。

通常情况下,'其他资源'存在于同一个系统中,但我不明白为什么外部Atom提要也不能被视为冲突。

因为如果外部服务器上的Atom订阅源是'固定的',那么用户所做的原始HTTP请求现在将工作。所以一个409种在这里是适当的。

+0

关于'422'我同意查询参数不是* entity *的一部分,因此可能很难返回*不可处理的实体*。但我真的不认为'409冲突'是一个更好的选择(从我在这里阅读https://tools.ietf.org/html/rfc7231#page-60)。 – Kakawait

+0

409以及我如何使用它的经验源于它在WebDAV(HTTP扩展)中的使用。它应用的方式意味着几乎是普遍的“请求没有错,如果在不同的资源状态发生变化后再次发送,它可能会成功”。这也是我如何从HTTP扩展中解释409,即使它在那里更加普遍和神秘。 – Evert