REST：HTTP PUT - 具有子实体的父实体

Question

当我在父记录上使用 HTTP PUT 时，REST 中是否有 standard/convention 指示子实体的预期行为？

比如我的Parent对象的初始状态是：

{
   "id": 1,
   "children": [
      {"id": 1, ...},
      {"id": 2, ...},
      {"id": 3, ...}
   ],
   ...
}

然后我在 /parents 上执行 HTTP PUT:

{
   "id": 1,
   "children": [
      {"id": 2, ...}, // I changed a property in here
   ],
   ...
}

我倾向于用 id 2 更新 Parent 和 Child，但是 id 的 1 和 3 的 Children 是否应该删除？

Answer 1

HTTP 和 REST 没有 'children' 的概念。如果您对资源执行 GET 请求，并且那里有称为“子项”的东西，那么这些子项基本上只是该资源的一部分。

PUT 请求应该替换资源的状态。如果您要用新的子列表替换子列表，那么是的，我希望这些更改能够保留。

Answer 2

Is there a standard/convention in REST that dictates the expected behavior with respect to Child entities when I use an HTTP PUT on Parent record?

没有

REST 没有“实体”或“记录”。它有“资源”。
REST 没有“children”。通用标识符拼写并不意味着两个资源之间存在关系。

PUT /parents HTTP/1.1
Content-Type: application/json

{
   "id": 1,
   "children": [
      {"id": 2, ...}, // I changed a property in here
   ],
   ...
}

此消息的意思是“使资源/parents 的表示与此消息的正文相匹配”。换句话说，将我的这份文件副本保存在您的文件之上。

在这种情况下，它表示 children 数组中应该只有一个条目，id：2。

服务器如何执行此操作是隐藏在 REST facade 后面的实现细节。消息只描述客户想要什么，而不描述客户得到什么。服务器拥有自己的资源，并且可以自由选择如何修改它们。这可能包括删除底层实体，或将它们标记为生命周期结束，或在不更改它们的情况下将它们从列表中删除，甚至 none 这些东西。

服务器确实需要对其响应稍微小心一些，以确保不要暗示新的表示与请求的正文匹配，除非这确实是它所做的。

REST：HTTP PUT - 具有子实体的父实体

REST: HTTP PUT - Parent with Child Entities

rest

webapi