Rest API可以在资源中返回单个用户数据吗？答案

【问题标题】：Rest API is it ok to return individual user data inside a resource?Rest API可以在资源中返回单个用户数据吗？
【发布时间】：2016-10-15 07:45:27
【问题描述】：

举个例子，假设我有一个 API，它处理将书籍的详细信息传回移动应用程序。用户可以浏览书籍列表，并将书籍添加到他们的愿望清单中。

我的问题是，当归还一本书或一组图书时，在每个图书资源中包含用户特定信息是否是一种好习惯？我的意思是，每本书都可以包含一个字段，表示该书是否在用户的愿望清单中，或者该清单是否会单独返回并由移动应用程序执行此检查。

移动应用程序开发人员更愿意调用 /books 并收到类似这样的响应；

{
  "books": [
    {
      "id":1,
      "name": "How to be good at everything",
      "price": 3.99,
      "in_wish_list": true
    },
    {
      "id":2,
      "name": "How to be good at nothing",
      "price": 6.50,
      "in_wish_list": false
    }
    ]
}

我认为我更希望将这些数据拆分到多个端点；

/user/29/wishlist

{
  "wishlist": [1,7,9,34,28]
}

/书

{
  "books": [
    {
      "id":1,
      "name": "How to be good at everything",
      "price": 3.99
    },
    {
      "id":2,
      "name": "How to be good at nothing",
      "price": 6.50
    }
    ]
}

这样，移动应用程序负责确定一本书是否在用户的愿望清单中。

我可以看到将用户数据嵌入图书资源的好处，但感觉不对。

我想知道其他人如何处理这种情况？

【问题讨论】：

几乎每个设计 API 的人都会遇到这种情况。看看我的answer 到一个非常相似的问题，它也应该适用于这里。
谢谢，客户端开发人员总是希望在单个请求/响应中获得尽可能多的信息，尤其是当移动应用程序中的特定视图需要这些信息时。虽然我同意这确实有助于与移动应用程序的集成，但我觉得 API 是专门为客户量身定制的。我想我正在做的是权衡返回针对移动应用程序视图量身定制的响应，反对跨多个端点返回响应，并通过进行更多调用来强制客户端应用程序完成更多工作。

标签： rest api-design

【解决方案1】：

现在这一切都取决于谁将使用您的 API，以及如何使用。如果需要显示用户心愿单的书籍，则必须使用单独的端点。当然，移动客户端开发人员会更喜欢一个大调用而不是几个较小的调用，但您也可以妥协并拥有一个单独的用户愿望列表端点（同样，如果有一个用例场景），并为每本书返回一个布尔值 - 那样，对您的 API 的调用次数甚至可能会减少。

【讨论】：

【解决方案2】：

从纯语义的角度来看，没有什么可以阻止您创建单独的资源“特定用户的图书数据”

GET /user-books?user_id=<user_id>
{
  "books": [
    {
      "id":1,
      "name": "How to be good at everything",
      "price": 3.99,
      "in_wish_list": true
    }
    …
  ]
}

它不违反任何 REST 约束。请注意，操作是无状态的（从查询字符串中获取user_id）并且可缓存。

【讨论】：