在 RESTful 服务中部分更新复杂类型

Question

我正在将 JSON 与 RESTful 服务结合使用。实现是这样的。

http://hostname/a 上的 GET 返回

{
    "a": {
        "b": {
            "c1": "data1",
            "c2": "data2" 
        } 
    }
}

http://hostname/a/b 返回

{
    "b": {
        "c1": "data1",
        "c2": "data2" 
    } 
}

我想知道 http://hostname/a

{
    "a": {
        "b": {
            "c1": "newdata" 
        } 
    }
}

它应该只用值“newdata”更新c1还是应该替换整个资源b，从而只包含c1（即c2被覆盖并且不再存在）

Answer 1

您偶然发现了我在过去几年处理 REST 时遇到的最具争议性的问题之一。

这是简单的答案：
普遍的共识是 HTTP PUT 方法具有替换语义，因此 c2 被覆盖并且不再存在。
最近引入了 PATCH 方法来帮助人们处理部分更新。

现在，该场景有两个复杂之处：

1. 为什么 PUT 必须具有替换语义？进行部分更新有哪些负面影响？我还没有听到真正令人信服的论据。

实际上，HTTP 规范并没有明确规定 PUT 具有替换语义，它 说：

PUT 方法要求
封闭的表示存储在
有效请求URI

，它还说

HTTP/1.1 没有定义 PUT 的方式
方法影响原点状态
服务器。

2. 如果您假设 PUT 具有替换语义，则服务器可能会在未替换的表示中包含某些内容，这是可以接受的。例如，如果表示包含链接，则对不包含这些链接的表示执行 PUT 不会“删除”这些链接。对于时间戳字段或上次修改的数据也是如此。永恒的问题是我们如何定义哪些内容在客户端省略时被删除，哪些内容因为服务器这么说而保留！

就我个人而言，我避免使用 PUT，因为我发现“替换”语义太有限制。然而，最近我开始被 Mike Kelly 和 Mike Amundsen 认为 PUT 可能比我们目前认为的更灵活。

Answer 2

首先，如果您更改“b”资源，为什么不将 POST（或 PUT）发送到 http://hostname/ a/b 而不是 http://hostname/a ？如果某个东西值得被指向/链接，那么根据 RIA 哲学，它应该作为资源来实现，并且有它自己的 URI。

Answer 3

如果您 PUT 到 http://hostname/a http://主机名/a/b?它们允许不同步多长时间？

如果答案是“它们没有被缓存”......？

“分层系统的主要缺点是它们增加了数据处理的开销和延迟，从而降低了用户感知的性能。对于支持缓存约束的基于网络的系统，这可以通过中介共享缓存的好处来抵消。 ” ——一篇著名的论文。