在 RESTful 服务中实现部分更新

近期 Alex Scordellis 发表了一篇文章，文章主题是如何针对客户端与 RESTFul 服务的交互进行建模和设计，实现部分资源的更新。

[在 REST In Practice （由 Ian Robinson 、 Jim Webber 和 Savas Parastatidis 合著）这本书中] 有个问题很让我困扰，作者们推荐使用 POST 方式更新资源的状态。这是根据对 PUT 语义的解释做出的选择。根据 HTTP 规范的描述：

如果请求的 URI 指向已经存在的资源，那么封装的实体应该被视为驻留在原始服务器上实体的修改后的版本。

在这本书里，作者们对此的解释是，在同一个 URI 里，PUT 请求封装的正文（body）中应该包含与 GET 请求的表现形式相同的元素。由于我们正在使用 HATEOAS 风格，表现形式包括链接和其他超媒体表现形式。其含义就是客户端 PUT 的内容应该同时包含业务数据（例如咖啡订单的新内容）和超媒体控件（工作流程中的下一个有效步骤）。

Alex 的观点是服务的超媒体和资源展现形式应该驱动客户端的工作流，并且他提出了四种可能的方法针对这种交互方式进行建模。其中一些例子可以从 RESTBucks 的文章里找到。

使用 PATCH […] 这种方式没有得到广泛的支持。我也觉得它语义上存在问题。从客户的角度来看，业务数据组成的订单（多少杯拿铁？）就是整个资源。客户并不会把这种方式看做是 PATCH，而会看做是替换，例如 PUT。PATCH 对于阐述像“在拿铁中放脱脂牛奶，而不是我原来定的全脂牛奶”这样的场景才有意义。 使用 POST 这种方法是书中推荐的。对我来说，它与 PATCH 有类似的问题。POST 意味着追加资源。在咖啡订单资源里 POST 一杯卡布奇诺，感觉就像追加了一杯卡布奇诺，而不是用卡布奇诺替换原有咖啡订单。 使用 PUT，包含超媒体 如果遵循严格的解释，PUT 应该包括整个展现形式，客户端同时发送完整新咖啡订单和所有的超媒体控件。
使用 PUT，不包含超媒体 客户端发送新订单的完整展现形式，但没有链接。我觉的这个概念是对的。客户端通过发送可用的部分数据的完整表现形式来满足 PUT 的需要，但并不负责哪些超媒体控件是有效的。

经过与 @serialseb 、 @iansrobinson 和 @jimwebber 讨论之后，Alex 总结了以下规则，这也满足了 PUT 作为动词语义的期望。

针对 GET 请求的响应，服务提供现有状态的完整表现形式，包括业务数据和有效的超媒体控件。客户端 PUT 由其负责的那部分数据的完整展现形式。

针对这一讨论，William Vambenepe补充了其他需要注意的事项：

我们来举个简单的例子。如果一个元素没有在部分更新中描述，这意味着什么？是明确的删除动作，表示在展现形式中删除该元素？或表示“不要改变其当前值”。如果是后者的话，我怎么做删除操作呢？是需要部分 DELETE，就像部分 PUT 一样？我希望不是，否则必须要有一种机制来实现类似 PUT 的部分删除元素。空值？这和并不存在的元素不是一回事。Nil 值？那么我如何在 JSON 中处理它呢？

他声称，设计部分资源更新是个十分困难的问题，现在正试图通过规范解决，例如 WSDM、WS-Management 和 WS-ResourceTransfer。

好消息是我们已经犯了很多错，而且已经得到了很多经验教训（参阅 technical rant 、 post-mortem 或 experiment ）。坏消息是有大量的新的错误还在等待着我们。

Stu Charlton 同样对这个问题抱有疑惑，而且他指出了这样一个事实，RESTFul 超媒体不能真正描述数据模型。据他而言，RESTful 服务要想具备更好的交互能力，还需要做以下两件事：

(a)[封闭的] 数据模型覆盖 80% 的公共用例，可以基于 JSON 和 XML 格式进行描述。

(b) 多媒体类型覆盖 80% 的公共用例，用来描述资源的生命周期和状态转移──换句话说，就是让 POST 在超媒体中实现自描述。因为计算机的世界不仅仅是更新数据，更多是关于抽象的描述。

针对 Alex 发表的文章的评论：

你应该具备 / 两种 / 资源：客户端的订单告诉服务器它想要什么，服务端的“票据”负责与客户端确认详细信息──增加任何其需要的附加数据、链接等。服务端的票据依赖于客户端的订单，包括在订单执行过程中任何内外部流程的状态。但谁来提供客户订单呢？当然是客户端！那么，除非你有一个不对称的设置，在这种情况下，客户端可以 POST 和 / 或 PUT 它的订单到服务器的某处。现在客户端可以一次性提交和改变 / 整个 / 订单资源，不需要担心任何服务端产生的数据。

有很多提议用来解决这一问题，而且，如果能够对资源进行恰当的建模，这个问题似乎可以很容易解决。很多时候会考虑到，把资源作为实体来支持 CRUD 操作也是同样的问题，只有把建模的资源作为“资源”和提供的服务，就像在 Duncan Craggs 示例中一样，才是解决问题的方案。不过更大的问题是如何让所有人都同意这个方案。请仔细阅读初始的文章和评论，并分享你的观点。

查看英文原文： Implementing Partial Updates In RESTful Services