RESTful API 是否应该为对象数组返回 404?
假设有一个带订单的产品。如果您请求 /products/product_id
,如果 product_id
不存在,它将返回 404
。但是,如果该产品不存在订单,/products/product_id/orders
应该返回 404
还是应该返回空数组?
Lets say there's a Product with Orders. If you ask for /products/product_id
, it will return a 404
if product_id
doesn't exist. But should /products/product_id/orders
return a 404
if no orders exist for this product or should it return an empty array?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
我会返回一个空集合。零订单的产品是一个完全有效的概念,因此空订单集合的存在比 404 更有意义,404 会推断该产品没有订单集合。
I would return an empty collection. A product with zero orders is a completely valid concept, so the existence of an empty orders collection makes more sense than a 404 which would infer that this product does not have a orders collection.
您确实应该只执行以下两件事中的一件
:返回
200(OK)
状态代码,并在正文中返回一个空数组。或者返回
204 (NO CONTENT)
状态代码和 NO 响应正文。对我来说,选项 2 在技术上似乎更正确,并且符合 REST 和 HTTP 原则。
然而,选项 1 对于客户端来说似乎更有效 - 因为客户端不需要额外的逻辑来区分两个(成功)状态代码。因为它知道它总是会收到一个数组,所以它只需检查它是否没有收到、一个或多个项目并进行适当的处理
You really should do only one of two things
Either Return a
200 (OK)
status code, and an empty array in the body.Or Return a
204 (NO CONTENT)
status code and NO response body.To me, option 2 seems more technically correct and keeping in line with REST and HTTP principles.
However, option 1 seems more efficient for the client - because the client does not need extra logic to differentiate between two (success) status codes. Since it knows that it will always receive an array, it simply has to check for whether it got none, one, or many items and process it appropriately
不要返回数组。在任何情况下都返回一个对象,就像
它允许您添加元数据(用于分页或其他)
通常使用http状态代码:200
此外,这是传统的Web API行为,由安全问题驱动:
https:// cheatsheetseries.owasp.org/cheatsheets/AJAX_Security_Cheat_Sheet.html#always-return-json-with-an-object-on-the-outside
Do not return arrays. Return an object in any case, like
it allows you to add metadata (for pagination or smth else)
usually with http status code: 200
Also, this is conventional web API behavior, driven by security concerns:
https://cheatsheetseries.owasp.org/cheatsheets/AJAX_Security_Cheat_Sheet.html#always-return-json-with-an-object-on-the-outside
在我看来:
我们在这里讨论的是http状态值,并且应该是更高级别的给出响应。
人们应该在层层代表中看到这一点。就像当你的 api 无法应答请求时,如果 api 调用本身不可用,那么你可以回复 404。
但是当你的调用存在时,它可以回复一组数据,但它是空的集合,您可以只返回 http 200,结果为空。
我会使用 http 状态值来指示请求验证,而不是直接使其依赖于更深 api 层中的内容。
或者人们可以严格遵循网上找到的协议,但没有人遵循它们......
In my opinion:
We're talking http status values here, and should be of a higher level of giving responses.
One should see this in layers of delegates. Like when your api is not able to answer a request, in case the api call itself is not available, then you could reply with a 404.
But when your call exists, and it could reply with a collection of data, but its an empty collection, you could return just a http 200, with an empty result.
I would use http status values to give an indication on the request validation, and not directly make it dependent on the content in the deeper api layers.
Or one could strictly follow protocols found on the net, but nobody follows them...