0

我已经提供了这样的 REST API 来获取基本用户信息和用户空间信息。

/v1/users/{user_id}/profile，它将返回这样的 JSON：

```json {

“id”：123，“名称”：“foo”，“性别”：0，“电子邮件”：“foo@gmail.com”，}```

/v1/users/{user_id}/space，它也返回一个 JSON：

```json { "sum_space":100, "used_space":20, }

现在，如果客户端（例如网页，第三个应用程序）有一个视图需要同时显示部分用户信息（例如“姓名”，“性别”）和部分用户空间信息（例如“sum_space”） , 我需要提供一个新的聚合 API/v1/users/{user_id}吗？

如果我提供这样一个聚合 API，它应该返回 User 和 Space 的所有属性吗？如果我这样做了，返回值将包含一些未使用的值，这将增加网络的带宽。但是如果这个 API 只是返回客户需要的东西，如果新的客户需求来了，我该怎么办（例如，只获取用户名和用户的 used_space）？

如果我不提供任何聚合API，所有客户端必须调用N次才能获取N种资源。如果需要过滤器搜索（例如获取总空间> 100 的用户列表），则客户端只能连续执行此操作。

我对这些很困惑，有什么要遵循的指导方针吗？

4

1 回答 1

0

在 提供基础数据/users/{id}。允许客户端包含可选的查询参数?expand=profile, space。如果他们同时选择两者，他们将获得来自所有三个端点的数据的详细响应。如果他们只选择，比如说，，profile那么他们会得到基础数据和配置文件数据。

如果您需要他们能够精确地限制他们需要的属性，您还可以支持?include查询参数，这可能看起来像GET /users/{id}?include=id,lastModifiedDate,profile.name&expand=profile并且可能会返回类似

{
    "id": 25,
    "lastModifiedDate": 0,
    "profile": {
        "name": "Bob Smith"
    }
}

你可以随意摆弄上面的 URI 结构。也许你更喜欢GET /users/{id}?include=id,lastModifiedDate&expand=profile[name]. 关键是您可以使用查询参数来定义您返回的信息类型。

如果您使用供应商特定的 MIME 类型，另一种选择是为不同形状的响应使用不同的 mime 类型。一种类型可能会返回配置文件和空间，而另一种类型会在向GET /users/{id}. 不过，这是一种特别生硬的乐器，听起来并不适合您的需求。

于 2016-08-29T14:30:08.137 回答