REST API具有相同的对象，但很轻

Question

我们正在构建一个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}

第3例

• 完整版：http://api.domain.com/myobject/ {objectId}？full = true
• 简易版：http://api.domain.com/myobject/ {objectId}

第4例？

欢迎任何指向REST API文档化资源的链接！

感谢。

Answer 1

这应该通过内容协商来处理，这就是它的用途。内容协商是客户端如何请求它想要查看的资源的表示。考虑图片的情况：image / x-canon-cr2，image / jpeg，image / png。

表面上是所有相同的图像，但格式不同。

因此，这是您真正想要用于资源的“精简”版本的机制。例如，您可以使用：

• 主要版本的“application / xhtml + xml”
• “application / xhtml + xml; lite”代表轻量级版本

所以，对于一个完整的资源：

GET /resource
Accept: application/xhtml+xml

对于轻型版本

GET /resource
Accept: application/xhtml+xml; lite

对于其中一种，但更喜欢精简版：

GET /resource
Accept: application/xhtml+xml;lite, application/xhtml+xml

（更具体的说明符，即带有; lite的，具有比普通applciation / xhtml + xml更高的优先级。）

如果您选择其中之一，但更喜欢完整版：

GET /resource
Accept: application/xhtml+xml;lite;q=0.1, application/xhtml+xml

那些没有品质因数的人默认为1.0，所以0.1小于1.0，如果可以通过Lite版本获得完整版本。

附录：

Accept上的q因子有效地用于显示客户的偏好。它用于确定客户端接受的媒体类型列表的优先级。它说“我可以处理这些媒体类型，但我更喜欢over over b over b”。

JPEG与PNG与精简版与完整版没有什么不同。 JPEG看起来像原始PNG的事实是一种视错觉，数据差别很大，它们有不同的用途。 JPEG不是“低质量”，而是不同的数据。这是“缺少的领域”。如果我想要，比方说，图像大小，JPEG将给我这些信息，就像PNG一样。在这种情况下，它的质量足以完成任务。如果不够，那么我不应该要求它。

我可以保证，如果我的客户端只能处理PNG并请求JPEG，那么该程序将无法“同样正常”工作。如果我的儿子想要鸡手指并且我给他菠菜奶油，那么就会有问题，尽管这些都是资源/晚餐的代表。

“application / xhtml + xml; lite”表示只是 - 表示，它不是资源本身。这就是使用单词表示的原因。表示只是来自实际资源的预测，这是服务器上的一些虚拟实体，以某种未定义的方式在内部实现。

有些陈述是规范性的，有些则不是。

表示通过媒体类型表现出来，媒体类型通过Con-neg和ACCEPT标头处理。如果你不能处理一个表示，那就不要问它。

这是一个问题。

我不知道“媒体播放器”与此讨论有什么关系。

Answer 2

第一种情况和第三种情况的优点是，一个URL用于单个资源，查询字符串用于请求该资源的特定视图。在它们之间进行选择是一个品味问题，但我更倾向于默认获取所有数据并保存查看子集的选项。