例如,您为用户/9运行一个GET请求,但没有id为#9的用户。 哪个是最佳响应码?
200好了 202年接受 204无内容 400错误请求 404未找到
例如,您为用户/9运行一个GET请求,但没有id为#9的用户。 哪个是最佳响应码?
200好了 202年接受 204无内容 400错误请求 404未找到
当前回答
在以前的项目中,我使用了404。如果没有用户9,则没有找到对象。因此404 Not Found是合适的。
如果对象存在,但没有数据,则为204 no Content。我认为在你的例子中,这个物体并不存在。
其他回答
起初,我认为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,而支持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.
如果期望资源存在,但它可能是空的,我认为它可能更容易得到一个200 OK的表示,表明这个东西是空的。
因此,我宁愿让/things返回一个带有{"Items":[]}的200 OK,而不是一个没有任何内容的204,因为这样,一个包含0项的集合可以被视为一个包含一个或多个项目的集合。
我将把204 No Content留给put和delete,在这种情况下,可能真的没有有用的表示。
在/thing/9不存在的情况下,404是合适的。
这样的事情可能是主观的,双方都有一些有趣和各种扎实的论点。然而,(在我看来)为丢失的数据返回404是不正确的。这里有一个简单的描述来说明这一点:
请求:能给我一些数据吗? 资源(API端点):我将在这里为您获取请求[发送潜在数据的响应]
没有问题,找到了端点,找到了表和列,因此查询了DB,并“成功”返回了数据!
现在,无论“成功响应”是否有数据都不重要,您要求“潜在”数据的响应,并且具有“潜在”数据的响应得到了满足。Null,空等是有效的数据。
200只代表我们的请求成功了。我正在请求数据,HTTP/REST没有任何问题,作为数据(尽管为空)返回我的“数据请求”是成功的。
返回一个200,让请求者在每个特定场景下处理空数据!
想想这个例子:
请求:查询用户ID为1234的“违规”表 资源(API端点):返回一个响应,但数据为空
此数据为空是完全有效的。这意味着用户没有违规行为。这是200,因为它是有效的,然后我可以这样做:
你没有违规,吃个蓝莓松饼!
如果你认为这是404,你在说什么?无法发现用户的违规行为?从语法上讲,这是正确的,但在REST世界中,成功或失败是关于请求的,这是不正确的。该用户的“违规”数据可以成功找到,没有违规-一个实数代表有效状态。
(厚颜无耻的注意。)
在你的标题中,你下意识地认为200是正确的回答:
对于有效请求但空数据,正确的REST响应代码是什么?
在选择使用哪种状态码时,抛开主观性和棘手的选择,以下是一些需要考虑的事情:
一致性。如果您使用404表示“无数据”,则在每次响应返回无数据时使用它。 同一个状态不要有多个意思。如果在没有找到资源时返回404(例如API端点不存在等),那么也不要因为没有返回数据而使用它。这只会让应对反应变成一种痛苦。 仔细考虑上下文。什么是“请求”?你说你想达到什么目的?
204号更合适。特别是当你有一个警报系统来确保你的网站是安全的,404在这种情况下会引起混乱,因为你不知道一些404警报是后端错误或正常的请求,但响应为空。