Question

为了举例，我说有一个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
    }
    ]
}

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

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

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

Answer 1

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

Answer 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）并且可以缓存。

Rest API是否可以在资源中返回单个用户数据？

2 个答案: