例如,您为用户/9运行一个GET请求,但没有id为#9的用户。 哪个是最佳响应码?
200好了 202年接受 204无内容 400错误请求 404未找到
例如,您为用户/9运行一个GET请求,但没有id为#9的用户。 哪个是最佳响应码?
200好了 202年接受 204无内容 400错误请求 404未找到
当前回答
根据w3,我相信以下几点:
2xx:
这类状态代码表示成功接收、理解并接受了客户机的请求。
4xx:
4xx类状态代码用于客户端似乎出现错误的情况。
如果客户端请求/users,并且它有用户要列出,响应代码将是200 OK(客户端请求有效)。
如果客户端请求/users并且没有数据,响应代码仍然是200 OK。 被请求的实体/资源是一个用户列表,列表存在,只是其中没有任何用户(如果给出空响应,可以使用204 No Content,尽管我认为空列表[]会更好)。 客户端请求是有效的,资源也确实存在,因此4xx响应代码在这里没有意义。
另一方面,如果客户端请求/users/9,而该用户不存在,那么客户端就犯了一个错误,请求了一个不存在的资源,一个用户。在这种情况下,回答404 Not Found是有意义的。
其他回答
Just an addition from a developer that struggled many times with this situation. As you might have noticed it is always a discussion whether you return a 404 or 200 or 204 when a particular resource does not exist. The discussion above shows that this topic is pretty confusing and opinion based ( while there is a http-status-code standard existing ). I personally recommend, as it was not mentioned yet I guess, no matter how you decide DOCUMENT IT IN YOUR API-DEFINITION. Of course a client-side developer has in mind when he/she uses your particular "REST"- api to use his/her knowledge about Rest and expects that your api works this way. I guess you see the trap. Therefor I use a readme where I explicitly define in which cases I use which status code. This doesn't mean that I use some random definion. I always try to use the standard but to avoid such cases I document my usage. The client might think you are wrong in some specific cases but as it is documented, there is no need for additional discussions what saves time for you and the developer.
One sentence to the Ops question: 404 is a code that always comes in my mind when I think back about starting to develop backend-applications and I configured something wrong in my controller-route so that my Controller method is not called. With that in mind, I think if the request does reach your code in a Controller method, the client did a valid request and the request endpoint was found. So this is an indication not to use 404. If the db query returns not found, I return 200 but with an empty body.
204号更合适。特别是当你有一个警报系统来确保你的网站是安全的,404在这种情况下会引起混乱,因为你不知道一些404警报是后端错误或正常的请求,但响应为空。
根据w3的帖子,
200好了
请求成功。随响应返回的信息取决于请求中使用的方法
202年接受
请求已接受处理,但处理尚未完成。
204无内容
服务器已经完成了请求,但不需要返回实体主体,并且可能希望返回更新后的元信息。
400错误请求
由于语法错误,服务器无法理解请求。客户不应该在没有修改的情况下重复请求
401年未经授权
请求需要用户身份验证。响应必须包含一个WWW-Authenticate报头字段
404未找到
服务器没有发现任何与Request-URI匹配的内容。没有说明这种情况是暂时的还是永久的
起初,我认为204是有意义的,但经过讨论,我相信404是唯一真正正确的回答。考虑以下数据:
用户:约翰,彼得
METHOD URL STATUS RESPONSE
GET /users 200 [John, Peter]
GET /users/john 200 John
GET /unknown-url-egaer 404 Not Found
GET /users/kyle 404 User Not found
GET /users?name=kyle` 200 []
DELETE /users/john 204 No Content
背景知识:
the search returns an array, it just didn't have any matches but it has content: an empty array. 404 is of course best known for url's that aren't supported by the requested server, but a missing resource is in fact the same. Even though /users/:name is matched with users/kyle, the user Kyle is not available resource so a 404 still applies. It isn't a search query, it is a direct reference by a dynamic url, so 404 it is. After suggestions in the comments, customizing the message of the 404 is another way of helping out the API consumer to even better distinguish between complete unknown routes and missing entities.
不管怎样,我的意见。
我不认为404是正确的回应。
如果使用404,如何知道是没有找到api,还是数据库中的记录没有找到?
从你的描述,我会使用200 OK,因为你的api执行所有逻辑没有任何问题。只是在数据库中找不到记录。所以,这不是API问题,也不是数据库问题,这是你的问题,你认为记录存在,但它不存在。因此,API执行成功,数据库查询执行成功,但没有发现任何返回。
因此,在这种情况下,我会用
200好了
使用空响应,如数组的[]或对象的{}。