首先，我阅读了一些相关的文章：
但是我仍然认为我应该在这里提出我的问题和想法。REST API中用于使用GET查询“尚未准备好，请稍后再试”资源的HTTP状态代码应该是什么？例如，客户端尝试通过对该URL进行HTTP GET来查询将来发生的所有本地新闻（！）：http : //example.com/news ? city= chicago& date= 2099-12-31因此服务器应回复什么？ ？
这些是我考虑过的http状态代码，它们的rfc定义以及为什么我不完全满意：
3xx重定向。注释：因为没有其他链接可以重定向到，所以这不是一个选择。
503服务不可用：由于服务器的暂时超载或维护，服务器当前无法处理该请求。言外之意是，这是一个暂时的状况，经过一段时间的延迟后会缓解。如果知道的话，延迟的长度可以在Retry-After头中指出。评论：重试行为是理想的，但是从语义上讲，这根本不是服务器的错误，因此所有5xx看起来都很奇怪。
4xx客户端错误。评论：看起来很有希望。见下文。
413请求实体太大：服务器拒绝处理请求，因为请求实体大于服务器愿意或能够处理的大小。如果条件是暂时的，服务器应该包括一个Retry-After头域，以指示它是暂时的，并且在什么时间之后客户端可以重试。评论：重试行为是所希望的，但是“实体太大”部分会产生误导。
417期望失败：此服务器无法满足在“期望”请求标头字段（请参见第14.20节）中给出的期望。评论：因此，它应该是由Expect请求标头引起的，不适用于我的情况。
406不可接受：根据请求中发送的接受标头，资源...不可接受。评论：因此，它是由Accept请求标题引起的，不适用于我的情况。
409冲突：由于与资源的当前状态冲突，请求无法完成。仅在预期用户可能能够解决冲突并重新提交请求的情况下才允许使用此代码。...响应PUT请求最有可能发生冲突。评论：这是关闭的。尽管我的情况与PUT无关，并且实际上不是由冲突引起的。
找不到404：服务器找不到与请求URI匹配的任何内容。评论：从技术上讲，我的网址路径（http://example.com/news）存在，它是引起问题的参数。在这种情况下，返回空集合而不是404可能更合适。
403禁止访问：服务器理解了该请求，但拒绝执行该请求。授权将无济于事，并且不应重复该请求。评论：通常应该在任何受限资源中使用它？
400错误的请求：由于语法格式错误，服务器无法理解该请求。客户不应在没有修改的情况下重复请求。评论：这不是我的情况。我的服务器理解请求，它的语法很好，只有含义不好。
2xx成功。评论：如果4xx不起作用，那么2xx呢？见下文。
200 OK。评论：很好。那么我应该在响应正文中包括什么？null或[]或{}或{“ date”：“ 2099-12-31”，“ content_list”：null}或...哪个更直观？另一方面，我更喜欢一种方法来区分较小的“未来新闻”错误与更常见的“所有查询条件都很好，今天就没有新闻”的情况。
202 Accepted：请求已被接受进行处理，但是处理尚未完成。该请求最终可能会执行，也可能不会最终执行。注释：假设我们可以在GET请求中使用202，则可以接受。然后参考200注释。
204无内容：服务器已完成请求，但不需要返回实体。注释：假设我们可以在GET请求中使用204，则可以接受。只是不知道这是否比202或200好。
有关2xx的更多信息：注释：我认为所有2xx响应都可能会缓存在某个地方。但就我而言，如果我为“明天的新闻”返回一个空的正文，则我不希望将其缓存。好的，明确指定“ no cache”标题应该有所帮助。
你的意见？
您正在检索当天的消息，这是有效的一天，没有任何消息。空体的200个响应或基于mediatype的有意义的响应似乎是合乎逻辑的。这取决于您与客户端决定的媒体类型。
如果日期格式错误（您要求输入11月45日，或要求输入不存在的城市），则404更为有意义。
另外，URL最好采用http://example.com/news/chicago/2099-12-31格式，因为这是您要检索的特定资源。这种格式也会使类似404的内容更加清晰。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句