Twitter使用404，并带有类似“找不到数据”的自定义错误消息。

裁判:https://developer.twitter.com/en/docs/basics/response-codes.html

TL; diana:

如果在/users/9上没有找到用户，则应该返回404。 如果在/users中没有找到用户?如果Id =9，则应该返回204。

长版:

在回顾了我自己对这些状态代码的使用和本文中的示例之后，我不得不说，如果在/users/9的url上没有找到用户#9,404是适当的响应。

今天在我的系统中，我们的Application Insights日志中充满了数百条记录的404错误，这使我们的日志变得混乱，因为我们决定在/users/9没有相关数据时返回404错误。然而，这并不意味着我们在设置响应时的方法是不正确的，相反，我认为这意味着我们在设置路由时的方法是不正确的。

如果您希望端点获得大量流量，并且担心记录太多404错误，那么您应该更改路由以符合您想要的状态码，而不是强制使用不适当的状态码。

我们已经决定对我们的代码做2个更改:

通过expect /users改变我们的工作路线?id = 9 将我们的错误代码更改为204，这样404就不会填满我们的AI日志。

最后，API的架构师需要了解他们的API将如何被使用，以及哪种路由将适合于该用例。

我相信在/users/9的情况下，您请求的资源是用户本身，用户#9;您要求服务器响应一个标识为“9”的对象，该对象恰好存在于包含单词“user”的路径中。如果没有找到该对象，则应该得到404。

但是，如果调用/users?id=9，我觉得你所请求的资源是用户控制器，同时也提供了更多的专一性，这样它就不会返回所有用户的完整列表。您要求服务器响应一个可以通过查询字符串中定义的ID号识别的特定用户。因此，如果没有找到数据，204对我来说是有意义的，因为即使没有找到数据，控制器也是。

查询字符串方法还完成了一些我认为不仅有助于API开发人员，而且有助于客户端开发人员(特别是初级开发人员或继承这段代码或调用它的代码的未来开发人员):

It becomes immediately clear to anyone involved that 9 is an ID, not some arbitrary number. This point may seem moot in such a basic example, but consider a system that uses GUIDs as row ID's or allows you to get data by a person's name, or even a system that is returning info for specific ZIP/postal codes instead of row ID's. It would be useful for all developers involved if, at a glance, they knew whether that identifying parameter was a first, last, full name, or a ZIP/postal code instead of an ID.

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.

我们现在看到的是两种范式之间的紧张关系。

在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将(正确地)表明它不存在。)

这个话题中的答案(在撰写本文时已经有26个)完美地说明了开发人员理解他们正在使用的构造的语义是多么重要。

如果不理解这一点，那么响应状态代码是响应的属性而不是其他属性就不明显了。这些代码存在于响应的上下文中，它们在此上下文中之外的含义是未定义的。

响应本身就是请求的结果。请求对资源进行操作。资源、请求、响应和状态代码是HTTP的结构，就HTTP而言:

HTTP提供了与资源(第2节)交互的统一接口，无论其类型、性质或实现如何，通过操作和传输表示(第3节)。

换句话说，响应状态码的范围受到一个接口的限制，该接口只关心一些目标资源，并处理用于与这些资源交互的消息。服务器应用程序逻辑超出了范围，您使用的数据也不重要。

当使用HTTP时，它总是与资源一起使用。资源被以太转移或操纵。在任何情况下，除非我们在量子世界中，资源要么存在要么不存在，不存在第三种状态。

如果发出HTTP请求来获取(传输)资源的表示(如本问题中所示)，而资源不存在，则响应结果应该显示一个带有相应404代码的失败。目标-获取表示-没有达到，资源没有找到。在HTTP上下文中不应该有对结果的其他解释。

RFC 7231超文本传输协议(HTTP/1.1):语义和内容，在这里多次提到，但主要是作为状态码描述的参考。我强烈建议通读整个文档，而不仅仅是第6节，以便更好地理解HTTP接口及其组件的作用域和语义。

使用公共枚举对响应内容进行编码，以允许客户端打开它并相应地派生逻辑。我不知道你的客户如何区分“数据未找到”404和“网络资源未找到”404之间的区别?您不希望有人浏览到userZ/9，并让客户端怀疑请求是否有效，但没有返回数据。