REST 将单个资源包装在集合中
我有一个小困境。
如果您有以下 URI 端点：
/item
/item/{id}
如果我向 /item 发出 GET 请求，我期望得到如下结果：
<Items>
<Item>...</Item>
<Item>...</Item>
...
</Items>
如果我向 /item/{id} 发出 GET 请求，我期望得到如下结果：
<Item>
...
</Item>
Some我的团队成员认为我们应该设计 API，以便当有人对 /item/{id} 执行 GET 时，它应该作为单个元素的集合返回。就像这样：
<Items>
<Item>...</Item>
</Items>
这对我来说似乎是错误的。你也觉得这不对吗？请解释原因，这样我可能会说服自己使用始终包装的资源版本，或者说服我的开发人员同事使用非包装的单一资源。
I have a small dilemma.
If you have the following URI endpoints:
/item
/item/{id}
If I make a GET request to /item I expect something like this:
<Items>
<Item>...</Item>
<Item>...</Item>
...
</Items>
If I make a GET request to /item/{id} I expect something like this:
<Item>
...
</Item>
Some of my fellow team members argue we should design the API so when someone does a GET for /item/{id} it should be returned as a collection of a single element. Like this:
<Items>
<Item>...</Item>
</Items>
This seems wrong to me. Does it seem wrong to you too? Please explain why, so I might convince either myself to go with the always wrapped version of the resource or my fellow devs to go with the non-wrapped single resource.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
最重要的是，这个问题的答案没有正确和错误之分。
然而，这就是我的想法。
如果你想返回单个项目，我倾向于这样做：
如果 {Id} 不存在，那么服务器应该返回 404。
如果我想返回项目的集合，我会这样做
如果没有项目，那么它应该返回带有空
如果它确实使客户端更容易处理只有一个元素的集合，那么您可以执行类似的操作。
这里的区别在于，如果 {Id} 不存在，那么我倾向于返回 200 而不是 404。
Most importantly, there is no right and wrong answer to this question.
However, here is what I think.
If you want to return a single item, I would tend to do this:
If the {Id} does not exist then the server should return a 404.
If I want to return a collection of items, I would do
If there are no items, then it should return a 200 with an empty
<Items/>element.If it really makes it easier for the client to deal with a collection that has just one element, then you could do something like this.
The difference here is that if the {Id} did not exist then I would tend to return 200 not a 404.
对我来说似乎违反直觉。通过使用一种方式从两个 GET 方法读取数据，您可能会节省客户端的代码工作量。当然，这可以通过使用额外的代码将单个 GET 方法包装在集合中来解决。
如果您想要真实世界的示例，
资源的表示
包裹在一个集合
基于 REST 的 API 的早期支持者，
也 遵循此模型
编辑：我们的 API 使用此 HTTP状态代码结构
Seems counterintuitive to me. You are potentially saving code effort on the client side by having one way of reading data from your two GET methods. This is of course countered by having extra code to wrap your single GET method in a collection.
If you want real world examples,
representation of a resource not
wrapped in a collection
early proponent of REST based API,
also follows this model
EDIT: Our API uses this HTTP status code structure
如果您考虑 REST 服务的消费端，我认为您的同事是对的，然后该服务可以将每个响应作为集合处理。还有一件事：如果 {id} 不存在，您的服务会返回什么？没有什么？然后，消费者必须检查空结果或错误响应、单个元素或集合。根据我的经验，在任何情况下获取集合（可能是空的）是 REST 服务提供服务的最方便的方式。
I think your colleagues are right if you think about the consuming side of your REST service, which then can handle every response as a collection. And there's one more thing: If the {id} did not exist, what does your service return? Nothing? Then the consumer has to check for either a null result or error response, a single element or a collection. According to my experience getting a collection in any case (which may be empty) is the most convenient way to be served by a REST service.