RESTAPI在资源中返回单个用户数据可以吗？

举个例子，假设我有一个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
    }
    ]
}

我认为我更喜欢将这些数据分割到多个端点

/用户/29/愿望列表

{
  "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，以及如何使用。如果需要显示用户希望的书籍，则必须使用单独的端点。当然，移动客户端开发人员更喜欢一个大的调用，而不是几个小的调用，但您也可以妥协，同时拥有一个单独的用户愿望列表端点（同样，如果有这样的用例场景），并在每本书中返回一个布尔值-这样，调用API的次数甚至可能会减少。

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

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

GET/user book？用户id=
{
“书籍”：[
{
“id”：1，
“姓名”：“如何做好每件事”，
“价格”：3.99，
“愿望清单中”：真
}
…
]
}

---

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

用户id

），并且可以缓存。

实际上，设计API的每个人都会处理这种情况。请看我的回答，这里也应该有类似的问题。谢谢，客户端开发人员总是希望在单个请求/响应中获得尽可能多的信息，特别是当移动应用程序中的特定视图需要这些信息时。虽然我同意这确实有助于与移动应用程序的集成，但我觉得API是专门为客户端定制的。我想我所做的是权衡针对移动应用程序视图定制的返回响应与跨多个端点返回响应之间的关系，以及通过拨打更多的电话迫使客户端应用程序做更多的工作。