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}

第三种情况

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

第四种情况？

欢迎任何指向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 c".

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

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

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

有些陈述是规范性的,有些则不是.

表示通过媒体类型表现出来,媒体类型通过Con-neg和ACCEPT标头处理.如果您无法处理表示,则不要求它.

这是一个问题.

我不知道"媒体播放器"与这个讨论有什么关系.

Answer 2

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