1

使用以下 API:

feed?url=XXX

对参数执行的验证url

  1. 如果丢失:400 Bad Request
  2. 如果为空/无效的 URL:422 Unprocessable Entity
  3. 如果 URL 不指向有效的RSS / Atom提要:422??

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

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

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

你有什么意见?

4

1 回答 1

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一种在这里是合适的。

于 2016-05-30T18:36:29.490 回答