例如,您为用户/9运行一个GET请求,但没有id为#9的用户。 哪个是最佳响应码?
200好了 202年接受 204无内容 400错误请求 404未找到
例如,您为用户/9运行一个GET请求,但没有id为#9的用户。 哪个是最佳响应码?
200好了 202年接受 204无内容 400错误请求 404未找到
当前回答
看完疑问后,为什么不应该使用404 ?
根据RFC 7231,正确的状态码是204
在上面的回答中,我注意到一个小错误:
1.—资源为:/users
2.- /users/8不是资源,而是:路由参数为8的资源/users,消费者可能注意不到,也不知道区别,但是发布者知道,而且必须知道!所以他必须为消费者返回一个准确的响应。时期。
so:
基于RFC: 404是不正确的,因为找到了资源/用户,但是使用参数8执行的逻辑没有找到任何内容作为响应返回,因此正确的答案是:204
这里的要点是:404甚至没有找到处理内部逻辑的资源
204是a:我找到了资源,逻辑被执行了,但我没有发现任何数据使用你在路由参数中给出的标准,所以我不能返回任何东西给你。对不起,核实你的标准后再打电话给我。
200:好吧,我找到了资源,逻辑被执行(即使当我不被迫返回任何东西)采取这一点,并在你的意愿使用它。
205:(GET响应的最佳选项)我找到了资源,逻辑被执行了,我有一些内容给你,好好使用它,哦,顺便说一下,如果你要在视图中共享这个,请刷新视图以显示它。
希望能有所帮助。
其他回答
根据w3的帖子,
200好了
请求成功。随响应返回的信息取决于请求中使用的方法
202年接受
请求已接受处理,但处理尚未完成。
204无内容
服务器已经完成了请求,但不需要返回实体主体,并且可能希望返回更新后的元信息。
400错误请求
由于语法错误,服务器无法理解请求。客户不应该在没有修改的情况下重复请求
401年未经授权
请求需要用户身份验证。响应必须包含一个WWW-Authenticate报头字段
404未找到
服务器没有发现任何与Request-URI匹配的内容。没有说明这种情况是暂时的还是永久的
我们现在看到的是两种范式之间的紧张关系。
在HTTP和REST中,URL标识一个资源,该用户/9资源包括9。因此HTTP应该返回404—未找到。这就是RESTful的定义。之后,你可以PUT user/9,然后当你得到下一次,你得到数据。这就是HTTP和REST的设计方式。
在HTTP级别,如果你不想要404,一个更好的URL会是user?Id =9,那么用户部分将被找到,函数可以进行自己的处理并返回它自己的“未找到”通知。
然而,为了方便指定api,使用user/9格式“更好”。这给我们留下了一个困境:这个请求是通过HTTP发出的,(固执的)正确的HTTP答案是404;但是从API使用者的角度来看,框架可能不能很好地处理404,他们想要200 +一个“not found”有效负载(204对许多框架来说也可能是问题)。
这种将API放在已经定义的协议(HTTP)之上的做法导致了这种紧张。当设计成一个真正的RESTful API时(并且正确地处理404错误),这是没有问题的。
如果您认为user/9应该返回200 +“not found”,那么您使用user作为RPC端点,然后在URL的其余部分编码参数。我认为这是一种糟糕的设计,与RESTful规范相反,并且完全理解我们是如何走到这一步的。
如果你控制了两端,考虑到你的服务器和客户端框架的限制,就做那些有效的事情。
(想想在用户/9上执行HEAD请求的后果——你不能在响应中提供任何内容。200将表明用户/9确实存在,而404将(正确地)表明它不存在。)
如果期望资源存在,但它可能是空的,我认为它可能更容易得到一个200 OK的表示,表明这个东西是空的。
因此,我宁愿让/things返回一个带有{"Items":[]}的200 OK,而不是一个没有任何内容的204,因为这样,一个包含0项的集合可以被视为一个包含一个或多个项目的集合。
我将把204 No Content留给put和delete,在这种情况下,可能真的没有有用的表示。
在/thing/9不存在的情况下,404是合适的。
我不认为404是正确的回应。
如果使用404,如何知道是没有找到api,还是数据库中的记录没有找到?
从你的描述,我会使用200 OK,因为你的api执行所有逻辑没有任何问题。只是在数据库中找不到记录。所以,这不是API问题,也不是数据库问题,这是你的问题,你认为记录存在,但它不存在。因此,API执行成功,数据库查询执行成功,但没有发现任何返回。
因此,在这种情况下,我会用
200好了
使用空响应,如数组的[]或对象的{}。
正如许多人所说的,404会误导客户端,如果请求uri不存在,或者请求的uri不能获取请求的资源,它不允许客户端进行区分。
200状态被期望包含资源数据——所以它不是正确的选择。 204状态意味着完全不同的东西,不应该用作GET请求的响应。
由于这样或那样的原因,所有其他现有状态都不适用。
我看到这个话题在很多地方被反复讨论。对我来说,很明显,要消除围绕这个话题的困惑,就需要一个专门的成功状态。比如“209 -没有资源显示”。
这将是一个2xx状态,因为找不到ID不应该被认为是客户端错误(如果客户端知道服务器DB中的所有内容,它们就不需要向服务器询问任何事情,不是吗?)这个专用状态将解决所有与使用其他状态争论的问题。
唯一的问题是:我如何让RFC接受这个标准?