如果仅仅因为没有响应数据而返回404，则任何客户端都会感到非常困惑。

对我来说，响应代码200和一个空的主体足以理解一切都是完美的，但没有数据匹配的要求。

正如许多人所说的，404会误导客户端，如果请求uri不存在，或者请求的uri不能获取请求的资源，它不允许客户端进行区分。

200状态被期望包含资源数据——所以它不是正确的选择。 204状态意味着完全不同的东西，不应该用作GET请求的响应。

由于这样或那样的原因，所有其他现有状态都不适用。

我看到这个话题在很多地方被反复讨论。对我来说，很明显，要消除围绕这个话题的困惑，就需要一个专门的成功状态。比如“209 -没有资源显示”。

这将是一个2xx状态，因为找不到ID不应该被认为是客户端错误(如果客户端知道服务器DB中的所有内容，它们就不需要向服务器询问任何事情，不是吗?)这个专用状态将解决所有与使用其他状态争论的问题。

唯一的问题是:我如何让RFC接受这个标准?

TL;DR:使用404

请看这个博客。这解释得很好。

博客对204的评论总结如下:

204 No Content作为浏览器的响应代码并不是特别有用(尽管根据HTTP规范，浏览器需要将其理解为“不要更改视图”的响应代码)。 然而，No Content对于ajax web服务非常有用，它可能想要表示成功而不需要返回任何东西。(特别是在DELETE或post这样不需要反馈的情况下)。

因此，您的问题的答案是在您的情况下使用404。204是一个专门的响应代码，您不应该经常将其返回给浏览器以响应GET。

其他响应代码甚至比204和404更不合适:

200 should be returned with the body of whatever you successfully fetched. Not appropriate when the entity you're fetching doesn't exist. 202 is used when the server has begun work on an object but the object isn't fully ready yet. Certainly not the case here. You haven't begun, nor will you begin, construction of user 9 in response to a GET request. That breaks all sorts of rules. 400 is used in response to a poorly formatted HTTP request (for instance malformed http headers, incorrectly ordered segments, etc). This will almost certainly be handled by whatever framework you're using. You shouldn't have to deal with this unless you're writing your own server from scratch. Edit: Newer RFCs now allow for 400 to be used for semantically invalid requests.

维基百科对HTTP状态码的描述尤其有用。 您也可以在www.w3.org上看到HTTP/1.1 RFC2616文档中的定义

我不认为404是正确的回应。

如果使用404，如何知道是没有找到api，还是数据库中的记录没有找到?

从你的描述，我会使用200 OK，因为你的api执行所有逻辑没有任何问题。只是在数据库中找不到记录。所以，这不是API问题，也不是数据库问题，这是你的问题，你认为记录存在，但它不存在。因此，API执行成功，数据库查询执行成功，但没有发现任何返回。

因此，在这种情况下，我会用

200好了

使用空响应，如数组的[]或对象的{}。

起初，我认为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.

不管怎样，我的意见。

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.