Question

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

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

```JSON {

“ID”：123， “名”：“富”， “性”：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），则客户端只能连续执行此操作。

我对此非常困惑，是否有任何指引可以遵循？

Answer 1

在/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}发出请求时，一种类型可能返回配置文件和空间，而另一种类型只返回一种或另一种类型。但这是一种特别钝的乐器，并不适合你的需要。