rest - REST API 中用于使用 GET 查询 “Not Ready Yet, Try Again Later” 资源的 HTTP 状态代码？

Question

首先，我阅读了一些相关帖子:

Best HTTP status code in REST API for “Not Ready Yet, Try Again Later”?关于GET项目

Is it wrong to return 202 “Accepted” in response to HTTP GET?关于GET项目

HTTP Status Code for Resource not yet available关于POST

HTTP status code for in progress?它是关于 GET 但没有明确的答案。

但我仍然认为我应该在这里提出我的问题和我的想法。 REST API 中用于使用 GET 查询“尚未准备好，稍后再试”资源的 HTTP 状态代码应该是什么？例如，客户端尝试通过对这个 url 进行 HTTP GET 来查询所有 future 发生的本地新闻(!): http://example.com/news?city=chicago&date=2099-12-31那么服务器应该回复什么？

这些是我考虑过的 http 状态代码、它们的 rfc 定义以及我不完全满意的原因:

3xx 重定向。 评论 : 不是一个选项，因为没有其他链接可以重定向到。

503 Service Unavailable:由于服务器暂时过载或维护，服务器当前无法处理请求。这意味着这是一个暂时的情况，将在一些延迟后得到缓解。如果已知，延迟的长度可以在 Retry-After 头中指示。 评论 : 重试行为是需要的，但从语义上讲，这种情况根本不是服务器的错，所以所有 5xx 看起来都很奇怪。

4xx 客户端错误。 评论 : 看起来很有希望。见下文。

413 Request Entity Too Large:服务器拒绝处理请求，因为请求实体大于服务器愿意或能够处理的。 ... 如果条件是临时的，服务器应该包含一个 Retry-After 头域来指示它是临时的，并且在什么时间之后客户端可以再试一次。 评论 :需要重试行为，但是“实体太大”部分有些误导。

417 期望失败:此服务器无法满足在 Expect 请求 header 字段(请参阅第 14.20 节)中给出的期望。 评论 : 所以它应该是由一个 Expect 请求头引起的，不适用于我的情况。

406 Not Acceptable: 根据请求中发送的接受 header ，资源...... Not Acceptable 。 评论 :所以它是由 Accept 请求头引起的，不适用于我的情况。

409 Conflict:由于与资源的当前状态冲突，请求无法完成。仅在预期用户可能能够解决冲突并重新提交请求的情况下才允许使用此代码。 ... 响应 PUT 请求时最有可能发生冲突。 评论 : 这个差不多。虽然我的情况与 PUT 无关，实际上也不是由冲突引起的。

404 Not Found:服务器没有找到任何与请求 URI 匹配的内容。 评论 : 从技术上讲，我的 url 路径 ( http://example.com/news ) 确实存在，它是导致问题的参数。在这种情况下，返回空集合而不是 404 可能更合适。

403 Forbidden:服务器理解请求，但拒绝执行。授权无济于事，不应重复该请求。 评论 : 一般这个应该用在任何受限制的资源中？

400 Bad Request:由于语法错误，服务器无法理解请求。客户端不应该在没有修改的情况下重复请求。 评论 : 在我的情况下不是这样。我的服务器理解请求，它的语法是好的，只是意思不好。

2xx 成功。 评论 : 如果 4xx 不起作用，那么 2xx 怎么样？见下文。

200 好的。 评论 : 美好的。那么我应该在响应正文中包含什么？ null or [] or {} or {"date": "2099-12-31", "content_list": null} or ...哪个更直观？另一方面，我更喜欢一种方法来清楚地区分次要的“ future 新闻”错误和更常见的“所有查询条件都很好，只是今天没有新闻”的情况。

202 Accepted:请求已被接受处理，但处理尚未完成。最终可能会或可能不会对请求采取行动。 评论 : 假设我们可以在GET请求中使用202，是可以接受的。然后引用200条评论。

204 No Content:服务端已经完成了请求，但是不需要返回一个entity-body。 评论 : 假设我们可以在GET请求中使用204，是可以接受的。就是不知道这个比202好还是200好。

更多关于 2xx:评论 :我假设所有 2xx 响应都可能缓存在某处。但就我而言，如果我为“明天的新闻”返回一个空正文，我不希望它被缓存。好的，明确指定“无缓存” header 应该会有所帮助。

你的意见？

Answer 1

使用 404。

您反对它是基于对 URI 的普遍理解，即不包括查询字符串。 “因为我有多个 URI 映射到同一个处理程序，”逻辑说，“我的资源确实存在，只是被查询字符串参数化了。”

这是不正确的。如 the URI spec本身在第 3.3 节(强调我的)中说，

"The path component contains data, usually organized in hierarchical form, that, along with data in the non-hierarchical query component (Section 3.4), serves to identify a resource within the scope of the URI's scheme and naming authority (if any)."

资源由 URI 标识，对绝对 URI 任何部分的任何更改都标识一个单独的资源。每天向你认识的每个人发一次推文，直到他们告诉你停止。因此一个 404是一个完美的匹配:“404(未找到)状态代码表明源服务器没有找到目标资源的当前表示或不愿意透露一个存在。”