web-services - 部分更新 RESTful 服务中的复杂类型

Question

我正在使用带有 RESTful 服务的 JSON。实现是这样的。

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

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

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

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

score 2 · Accepted Answer

您遇到了我在过去几年处理 REST 时看到的最有争议的问题之一。

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

现在，这里有两个复杂的场景：

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

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

但是，它也说

HTTP/1.1 没有定义 PUT 方法如何影响源服务器的状态。

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

就个人而言，我避免了 PUT，因为我发现“替换”语义太受限制了。然而，最近我开始被Mike Kelly和Mike Amundsen说服，也许 PUT 应该被认为比我们目前认为的更灵活。

score 1 · Accepted Answer

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

score 0 · Accepted Answer

如果你 PUT 到http://hostname/a缓存的 http://hostname/a/b副本会发生什么？允许它们不同步多长时间？

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

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

3 回答 3