首先，我阅读了一些相关的帖子：
- REST API 中“尚未准备好，稍后再试”的最佳 HTTP 状态代码？这是关于 GET 一个项目
- 响应 HTTP GET 返回 202 “Accepted” 是错误的吗？这是关于 GET 一个项目
- 资源的 HTTP 状态码尚不可用这是关于 POST
- 正在进行的 HTTP 状态代码？这是关于 GET 但没有明确的答案。
但我仍然认为我应该在这里提出我的问题和想法。REST API 中用于使用 GET 查询“尚未准备好，稍后再试”资源的 HTTP 状态代码应该是什么？例如，客户端尝试通过对以下 url 进行 HTTP GET 来查询未来发生的所有本地新闻（！）：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 期望失败：此服务器无法满足在期望请求标头字段（请参阅第 14.20 节）中给出的期望。评论：所以它应该是由 Expect 请求标头引起的，不适用于我的情况。
406 Not Acceptable: 根据请求中发送的接受标头，资源...不可接受。评论：所以它是由 Accept 请求标头引起的，不适用于我的情况。
409 Conflict：由于与资源的当前状态冲突，请求无法完成。仅在预期用户可能能够解决冲突并重新提交请求的情况下才允许使用此代码。...响应 PUT 请求时最有可能发生冲突。评论：这个很接近。尽管我的案例与 PUT 无关，实际上也不是由冲突引起的。
404 Not Found：服务器没有找到任何匹配 Request-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 ...哪个更直观？另一方面，我更喜欢一种方法来清楚地区分小的“未来新闻”错误和更常见的“所有查询条件都很好，只是今天没有新闻”的情况。
202 Accepted：请求已被接受处理，但处理尚未完成。该请求最终可能会或可能不会被执行。评论：如果我们可以在 GET 请求中使用 202，则可以接受。然后参考200评论。
204 No Content：服务器已完成请求，但不需要返回实体主体。评论：如果我们可以在 GET 请求中使用 204，这是可以接受的。就是不知道这个比202好还是200好。
有关 2xx 的更多信息：评论：我认为所有 2xx 响应都可能会缓存在某处。但就我而言，如果我为“明天的新闻”返回一个空正文，我不希望它被缓存。好的，明确指定“无缓存”标头应该会有所帮助。
你的意见？