REST API 具有相同的对象，但很轻
我们正在构建一个 REST API，我们希望返回相同的对象，但一次调用是“轻型”版本（没有所有字段），
最佳实践是什么？
第一个案例
- 完整版：http://api.domain.com/myobject/{objectId}
- 精简版： http://api.domain.com/myobject/{objectId}?filter=light
第二种情况
- 完整版：http://api.domain.com/myobject/{objectId}/details
- 轻型版本：http://api.domain.com/myobject/{objectId}
第三个案例
- 完整版本：http://api.domain.com/myobject/{objectId}?full=true
- 轻型版本：http://api.domain.com/myobject/{objectId}
第四种情况？
欢迎任何指向 REST API 文档资源的链接！
谢谢。
We are building a REST API and we want to return the same object, but one call is a 'light' version (without all the field)
what is the best practice ?
1st case
- full version: http://api.domain.com/myobject/{objectId}
- light version: http://api.domain.com/myobject/{objectId}?filter=light
2nd case
- full version: http://api.domain.com/myobject/{objectId}/details
- light version: http://api.domain.com/myobject/{objectId}
3rd case
- full version: http://api.domain.com/myobject/{objectId}?full=true
- light version: http://api.domain.com/myobject/{objectId}
4th case ?
Any link to a documented resource of a REST API is welcome !
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这应该通过内容协商来处理，这就是它的目的。内容协商是客户端如何请求它想要查看的资源的表示形式。考虑图片的情况：image/x-canon-cr2、image/jpeg、image/png。
表面上都是相同的图像，但格式不同。
因此，这是您真正想要用于资源的“精简”版本的机制。例如，您可以使用：
因此，对于完整资源：
对于轻量级版本
对于任一版本，但更喜欢lite 版本：（
更具体的说明符，即带有 ;lite 的说明符，比正常的 applciation/xhtml+xml 具有更高的优先级。）
如果您选择其中之一，但更喜欢完整版本：
那些没有品质因数的默认为 1.0，所以0.1 小于 1.0，如果在精简版上可用，您将获得完整版。
附录：
Accept 上的 q 因子有效地用于显示客户的偏好。它用于确定客户端接受的媒体类型列表的优先级。它说“我可以处理这些媒体类型，但我更喜欢a而不是b而不是c”。
JPEG 与 PNG 与精简版与完整版没有什么不同。事实上，JPEG 看起来与原始 PNG 很像，这是一种视错觉，数据相差很大，而且它们有不同的用途。 JPEG 并不是“低质量”，而是不同的数据。这是“缺失的领域”。例如，如果我想要图像大小，JPEG 会像 PNG 一样提供该信息。在这种情况下，它的质量足以完成任务。如果这还不够，那么我就不应该提出这样的要求。
我可以保证，如果我的客户端只能处理 PNG 并请求 JPEG，那么该程序将无法“同样良好地工作”。如果我儿子想要鸡指，而我给他奶油菠菜，就会出现问题，即使这两者都是资源/晚餐的代表。
“application/xhtml+xml;lite”表示只是一种表示，它不是资源本身。这就是使用“表示”这个词的原因。这些表示都是来自实际资源的简单投影，实际资源是服务器上以某种未定义的方式在内部实现的虚拟实体。
有些表述是规范的，有些则不是。
表示通过媒体类型来体现，媒体类型通过 Con-neg 和 ACCEPT 标头进行处理。如果您无法处理代表，请不要提出要求。
这是一个 con-neg 问题。
我不知道“媒体播放器”与此讨论有什么关系。
This should be handled through content negotiation, that's what its for. Content negotiation is how a client can request which representation of the resource it wants to see. Consider the case of a picture: image/x-canon-cr2, image/jpeg, image/png.
Ostensibly all the same image, but in different formats.
So, this is the mechanism you really want to use for a "lite" version of your resource. For example you could use:
So, for a full resource:
For a light version
For either, but preferring the lite version:
(the more specific specifier, i.e. the one with ;lite, has higher priority over the normal applciation/xhtml+xml.)
If you will take either, but prefer the full version:
Those without a quality factor default to 1.0, so 0.1 is less than 1.0 and you will get the full version if available over the lite version.
Addenda:
The q factor on Accept is effectively used to show the preferences of the client. It is used to prioritize the list of media types that the client accepts. It says "I can handle these media types, but I prefer a over and b over c".
A JPEG vs a PNG is no different than the lite vs full version. The fact that a JPEG looks anything like the original PNG is an optical illusion, the data is far different, and they have different uses. A JPEG is not "lower quality", it's different data. It's "missing fields". If I want, say, the image size, the JPEG will give me that information just as well as a PNG would. In that case, it's quality is adequate for the task. If it wasn't adequate, then I shouldn't be requesting it.
I can guarantee that if I have a client that can only process PNG and ask for a JPEG, then that program will not "work equally well" with it. If my son wants Chicken Fingers and I give him Cream of Spinach, there are going to be issues, even though both of those are representations of the the resource /dinner.
The "application/xhtml+xml;lite" representation is just that -- a representation, it is NOT the resource itself. That's why the word representation is used. The representations are all simply projections from the actual resource, which is some virtual entity on the server realized internally in some undefined way.
Some representations are normative, some are not.
Representations are manifested through media types, and media types are handled via Con-neg and the ACCEPT header. If you can't handle a representation, then don't ask for it.
This is a con-neg problem.
I don't know what a "media player" has to do with this discussion.
第一种情况和第三种情况的优点是，一个 url 用于单个资源，并且查询字符串用于请求该资源的特定视图。在它们之间进行选择是一个品味问题，但我倾向于默认获取所有数据并保存查看子集的选项。
The 1st case and 3rd case have the advantage that one url is used for a single resource and the query string is used to request a particular view of that resource. Choosing between them is a matter of taste, but I tend to prefer a default of getting all the data and saving the options for viewing subsets.