0

假设我们有以下用户文档：

{
  "_id": "1",
  "firstName": "Joe",
  "hobbies": [
     "_id": "1",
     "name": "music",
     "talented": true
   ],
}

因此，假设我们想要发布、修补或删除 Joey 的一项爱好。我们应该如何继续使用 rest api？

我想过做这样的事情：

POST - /users/:id/hobbies


PATCH - /users/:id/hobbies/:id


DELETE - /users/:id/hobbies/:id

这看起来非常语义化且易于阅读，但另一方面，将子文档名称作为资源附加到路由中感觉不对，因为它是子文档并且属于主用户文档。

所以，我认为的另一种方法是简单地为主用户文档打补丁：

PATCH - /users/:id/

哪种休息路线结构对于完成这些任务是正确的？

4

1 回答 1

2

假设我们有以下用户文档我们应该如何继续使用 rest api？

通过将文档视为文档：在本地进行编辑，并将结果发送回服务器。

假设此文档可在 上获得/users/1/，我们只会发回一份删除了爱好的陈述...

PUT /users/1/

{
  "_id": "1",
  "firstName": "Joe",
  "hobbies": [
   ],
}

使用 PATCH 而不是 PUT 很好（假设我们发送一个补丁文档作为消息体）。从技术上讲，您也可以使用 POST，但 POST 在这里并没有真正为您提供任何优势。

/users/:id/hobbies
/users/:id/hobbies/:id

使用这样的标识符的问题在于，通用客户端不会识别它们与它们有任何关系/users/:id/- 所以即使您发送消息删除爱好，客户端的本地缓存副本也不会更新（因为它使用不同的键）。

现在，如果您的资源是使用链接设计的

{
  "_id": "1",
  "firstName": "Joe",
  "hobbies": [ { "href": "/users/1/hobbies/4" } ]
}

然后我们仍然会使用/users/1/从集合中添加/删除爱好，但如果我们想修改爱好本身的表示，那么我们将使用/users/1/hobbies/4.

如果爱好集合本身是一个链接......

{
  "_id": "1",
  "firstName": "Joe",
  "hobbies": "/users/1/hobbies"
}

然后我们会通过发送消息来添加/删除爱好/users/1/hobbies。

考虑网页可能会有所帮助 - 网页的 HTML 表示通常包含指向图像或脚本的链接，这些链接与页面本身分开获取和缓存。如果我们想编辑 HTML，我们将使用页面的标识符发送请求，如果我们想更改脚本，我们将发送脚本的标识符。

于 2019-05-08T17:58:33.137 回答