首先,我读了一些相关的帖子:
但我仍然认为我应该在这里提出我的问题和想法.REST API中的HTTP状态代码应该是什么？使用GET到QUERY"未准备好,稍后再试"资源？例如,客户端尝试通过对此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期望失败:此服务器无法满足Expect请求标头字段(请参阅第14.20节)中给出的期望.注释:所以它应该是由Expect请求标头引起的,不适用于我的情况.
406 Not Acceptable:资源...根据请求中发送的accept头不可接受.注释:所以它是由Accept request-header引起的,不适用于我的情况.
409冲突:由于与资源的当前状态发生冲突,无法完成请求.此代码仅在预期用户可能能够解决冲突并重新提交请求的情况下才允许....响应PUT请求最有可能发生冲突.评论:这个很接近.虽然我的情况不是关于PUT,实际上并不是由冲突造成的.
404 Not Found:服务器未找到与Request-URI匹配的任何内容.评论:从技术上讲,我的网址路径(http://example.com/news)存在,它是导致问题的参数.在这种情况下,返回空集合而不是404,可能更合适.
403 Forbidden:服务器理解请求,但拒绝履行请求.授权无效,请求不应重复.评论:通常这应该用于任何受限制的资源？
400错误请求:由于语法格式错误,服务器无法理解请求.客户端不应该在没有修改的情况下重复请求.评论:在我的案例中并非如此.我的服务器理解请求,它的语法很好,只有意思不好.
2xx成功.评论:如果4xx不起作用,2xx怎么样？见下文.
200好的.评论:很好.那么我应该在响应体中包含什么呢？null或[]或{}或{"date":"2099-12-31","content_list":null}或者......哪一个更直观？另一方面,我更喜欢一种方法,以明确区分未成年人"未来新闻"错误与更常见的"所有查询标准都很好,这一天没有新闻"的情况.
202 Accepted:已接受请求进行处理,但处理尚未完成.该请求最终可能会或可能不会被采取行动.注释:假设我们可以在GET请求中使用202,则可以接受.然后参考200评论.
204 No Content:服务器已完成请求,但不需要返回实体.注释:假设我们可以在GET请求中使用204,则可以接受.只是不知道这是否优于202或200.
更多关于2xx:评论:我认为所有2xx响应都可能在某处缓存.但在我的情况下,如果我为"明天的新闻"返回一个空身,我不希望它被缓存.好的,明确指定"无缓存"标题应该有所帮助.
你的意见？
您正在检索当天的新闻，这是有效的一天，只是没有任何新闻。空正文的 200 响应，或者基于媒体类型的有意义的响应似乎是合乎逻辑的。这取决于您与客户决定的媒体类型。
如果日期格式错误（您询问的是 11 月 45 日，或者询问的是不存在的城市），404 会更有意义。
顺便说一句，URL 采用http://example.com/news/chicago/2099-12-31格式会更好，因为这是您要检索的特定资源。这种格式也会使 404 之类的事情变得更加清晰。
| 归档时间： |
|
| 查看次数： |
4996 次 |
| 最近记录： |