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

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

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

现有的答案没有详细说明使用路径参数还是查询参数是有区别的。

In case of path parameters, the parameter is part of the resource path. In case of /users/9, the response should be 404 because that resource was not found. /users/9 is the resource, and the result is unary, or an error, it doesn't exist. This is not a monad. In case of query parameters, the parameter is not part of the resource path. In case of /users?id=9, the response should be 204 because the resource /users was found but it could not return any data. The resource /users exists and the result is n-ary, it exists even if it is empty. If id is unique, this is a monad.

使用路径参数还是查询参数取决于用例。我更喜欢将路径参数用于强制的、规范的或标识参数，将查询参数用于可选的、非规范的或属性参数(如分页、排序区域设置等)。在REST API中，我会使用/users/9而不是/users?Id =9，特别是因为可能嵌套获取“子记录”，如/users/9/ SSH -keys/0获取第一个公共SSH密钥或/users/9/address/2获取第三个邮政地址。

我更喜欢使用404。原因如下:

Calls for unary (1 result) and n-ary (n results) methods should not vary for no good reason. I like to have the same response codes if possible. The number of expected results is of course a difference, say, you expect the body to be an object (unary) or an array of objects (n-ary). For n-ary, I would return an array, and in case there are not results, I would not return no set (no document), I would return an empty set (empty document, like empty array in JSON or empty element in XML). That is, it's still 200 but with zero records. There's no reason to put this information on the wire other than in the body. 204 is like a void method. I would not use it for GET, only for POST, PUT, and DELETE. I make an exception in case of GET where the identifiers are query parameters not path parameters. Not finding the record is like NoSuchElementException, ArrayIndexOutOfBoundsException or something like that, caused by the client using an id that doesn't exist, so, it's a client error. From a code perspective, getting 204 means an additional branch in the code that could be avoided. It complicates client code, and in some cases it also complicates server code (depending on whether you use entity/model monads or plain entities/models; and I strongly recommend staying away from entity/model monads, it can lead to nasty bugs where because of the monad you think an operation is successful and return 200 or 204 when you should actually have returned something else). Client code is easier to write and understand if 2xx means the server did what the client requested, and 4xx means the server didn't do what the client requested and it's the client's fault. Not giving the client the record that the client requested by id is the client's fault, because the client requested an id that doesn't exist.

最后一点:一致性

GET /用户/ 9 PUT /users/9和DELETE /users/9

PUT /users/9和DELETE /users/9已经必须在成功更新或删除的情况下返回204。如果用户9不存在，它们应该返回什么?根据所使用的HTTP方法将相同的情况显示为不同的状态代码是没有意义的。

Besides, not a normative, but a cultural reason: If 204 is used for GET /users/9 next thing that will happen in the project is that somebody thinks returning 204 is good for n-ary methods. And that complicates client code, because instead of just checking for 2xx and then decoding the body, the client now has to specifically check for 204 and in that case skip decoding the body. Bud what does the client do instead? Create an empty array? Why not have that on the wire, then? If the client creates the empty array, 204 is a form of stupid compression. If the client uses null instead, a whole different can of worms is opened.

根据w3的帖子，

200好了

请求成功。随响应返回的信息取决于请求中使用的方法

202年接受

请求已接受处理，但处理尚未完成。

204无内容

服务器已经完成了请求，但不需要返回实体主体，并且可能希望返回更新后的元信息。

400错误请求

由于语法错误，服务器无法理解请求。客户不应该在没有修改的情况下重复请求

401年未经授权

请求需要用户身份验证。响应必须包含一个WWW-Authenticate报头字段

404未找到

服务器没有发现任何与Request-URI匹配的内容。没有说明这种情况是暂时的还是永久的

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

我强烈反对404，而支持204或200的空数据。或者至少应该使用带有404的响应实体。

请求被接收并被正确处理——它确实触发了服务器上的应用程序代码，客户机可能没有犯任何错误，因此整个客户机错误代码(4xx)类可能不合适。

更重要的是，404的发生有很多技术原因。例如，应用程序在服务器上被暂时停用或卸载，代理连接问题等等。

当然，这种情况下存在5xx错误类，但实际上，受影响的中间件组件通常无法知道错误在它们这一边，然后只是假设错误在客户端，然后响应404而不是500/503。

因此，仅根据状态代码，客户端无法区分404(表示“您正在寻找的东西不存在”)和404(表示“有严重错误，请将此错误报告给运维团队”)。

This can be fatal: Imagine an accounting service in your company that lists all the employees that are due to an annual bonus. Unfortunately, the one time when it is called it returns a 404. Does that mean that no-one is due for a bonus, or that the application is currently down for a new deployment and the 404 is actually coming from the tomcat that it's supposed to be installed into, instead of from the application itself? These two scenarios yield the same status code, but they are fundamentally different in their meaning.

对于需要知道所请求的资源不存在而不是暂时不可访问的应用程序来说，没有响应实体的404几乎是行不通的。

此外，许多客户端框架通过抛出异常来响应404，而不询问进一步的问题。这迫使客户端开发人员捕获异常，对其进行评估，然后基于此决定是否将其记录为由监视组件捕获的错误，或者是否忽略它。这对我来说也不太好。

The advantage of 404 over 204 is that it can return a response entity that may contain some information about why the requested resource was not found. But if that really is relevant, then one may also consider using a 200 OK response and design the system in a way that allows for error responses in the payload data. Alternatively, one could use the payload of the 404 response to return structured information to the caller. If he receives e.g. a html page instead of XML or JSON that he can parse, then that is a good indicator that something technical went wrong instead of a "no result" reply that may be valid from the caller's point of view. Or one could use a HTTP response header for that.

尽管如此，我还是更喜欢204或200的空白回复。这样，请求的技术执行状态就与请求的逻辑结果分开了。2xx的意思是“技术执行ok，这就是结果，处理它”。

我认为在大多数情况下，应该让客户来决定一个空的结果是否可以接受。通过返回404而不返回响应实体(尽管技术执行正确)，客户端可能决定将根本不是错误的情况视为错误。

Another perspective: From an operations point of view a 404 may be problematic. Since it can indicate a connectivity/middleware problem rather than a valid service response, i would not want a fluctuating number of "valid" 404s in my metrics/dashboards that might conceal genuine technical issues (e.g. a misconfigured proxy somewhere in the request routing) that should be investigated and fixed. This is further excarbated by some APIs even using 404 instead of 401/403 (e.g. gitlab does such a thing), to conceal the information that the request URI would have been valid but the request lacked authorization to access it. In this case too a 404 should be treated as a technical error and not as a valid "resource not found" result.

Edit: Wow, this has caused a lot of controversy. Here is another argument against 404: Strictly from a HTTP spec (RFC7231) point of view, 404 does not even mean that a resource does not exist. It only means that the server has no current representation of the requested resource available, and this even may be only temporary. So strictly by HTTP spec, 404 is inherently unreliable regarding the nonexistence of a requested thing. If you want to communicate that the requested thing positively does not exist, do not use 404.