【问题标题】:REST: Offer detailed and overview response for the same resourceREST:为同一资源提供详细和概览响应
【发布时间】:2015-06-04 19:19:39
【问题描述】:

我有一个资源说rest/users,其中包含具有许多属性的用户。现在我想提供三件事。

  • 包含每个用户名和 ID 的概览(以节省流量)
  • 包含用户每个属性的详细视图(如果客户端需要所有数据,则保存请求)
  • 单个用户(通过rest/users/{id}

我有两个想法来解决这个问题。

  1. 使用查询参数,例如视图,可以是详细信息或概览
  2. 访问rest/users时返回总览,访问rest/users/all时返回详细视图

RESTful 解决方案是哪一种?还是有更好的?我是否应该首先避免提供两个回复?

编辑:这不是 architectural design for REST API with views across resources 的重复,因为想要对同一资源有不同的答案,而不是不同资源的组合。

Lutz Horn 的回答为我解决了问题。

【问题讨论】:

标签: rest


【解决方案1】:

RESTful 解决方案是哪一种?

两者都不是 RESTful。请求时

GET /rest/users

您可以使用Content Negotiation 来区分简短列表和详细用户列表。提出要求

GET /rest/users
Accept: application/vnd.example.com.users.short+json

将返回 短用户信息列表的 JSON 表示,一个请求

GET /rest/users
Accept: application/vnd.example.com.users.detailed+json

将返回 包含所有详细信息的用户列表的 JSON 表示形式

请注意,我在 Accept 标头中组成了 MIME 类型。重要的部分是vnd,它是基于现有 MIME 类型定义您自己的 MIME 类型的标准方法(在本例中为 application/json)。

不要使用查询参数或不同的 URL 来区分,因为您正在请求相同的资源(用户列表)以不同的表示形式 (简短而详细)。两者的 URL 相同,Accept 标头不同。

【讨论】:

  • 很好的答案!谢谢,一直想知道如何以 RESTful 方式实现它。您是否有任何指向该解决方案是 RESTful 的文档的链接?
  • 没有链接,抱歉。但如果你稍微思考一下 REST 的 Uniform Interface,我认为这种方法是 RESTful 的就很明显了。
  • 感谢您非常有帮助的回答!我没有考虑过使用不同的标头,但它比我的解决方案更有意义。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2016-12-13
  • 1970-01-01
  • 2020-05-23
  • 2021-08-02
相关资源
最近更新 更多