REST 服务语义；包括未更新的属性？答案

【问题标题】：REST service semantics; include properties not being updated?REST 服务语义；包括未更新的属性？
【发布时间】：2015-10-31 07:33:52
【问题描述】：

假设我有一个名为Person 的资源。我可以通过将POST 更新为/data/Person/{ID} 来更新Person 实体。为简单起见，假设一个人具有三个属性，名字、姓氏和年龄。

GET /data/Person/1 产生类似：

{ id: 1, firstName: "John", lastName: "Smith", age: 30 }.

我的问题是关于此人的更新以及执行此操作的服务的语义。假设我想更新 John，他现在 31 岁。在设计方法方面，我看到 API 有两种工作方式：

选项 1：

POST /data/Person/1 和 { id: 1, age: 31 } 做正确的事。隐含地，任何未提及的属性都不会更新。

选项 2：

POST /data/Person/1 与 GET 接收的完整对象 - 必须指定所有属性，即使许多属性没有更改，因为 API（在缺少属性的情况下）会假设它的正确值是null。

从推荐的设计角度来看，哪个选项是正确的？选项 1 很有吸引力，因为它简短而简单，但在某些情况下具有模棱两可的缺点。选项 2 让您来回发送大量数据，即使数据没有变化，也不会告诉服务器此有效负载真正重要的是什么（只有年龄发生了变化）。

【问题讨论】：

就我个人而言，在我实施了 RESTful API 的项目中，我总是使用选项 1，但这只是我对此事的看法。这个问题真的取决于你作为开发者。顺便说一句，如果您正在开发 RESTful api，您应该使用 PUT 而不是 POST 来更新记录
所以@mituw16 在使用选项 1 时，如果您需要将属性更新为 null，您可以显式发送它吗？
是的，当试图清空一个属性时，我传回 null

【解决方案1】：

选项 1 - 更新资源的子集 - 现在在 HTTP 中被形式化为 PATCH 方法。选项 2 - 更新整个资源 - 是 PUT 方法。

在实际场景中，通常只想上传资源的一个子集。这对于请求的性能和客户端的模块化/多样性更好。

因此，PATCH 现在在典型的 API (imo) 中比 PUT 更有用，但如果您愿意，可以同时支持两者。有一些平台可能不支持 PATCH 的极端情况，但我相信它们现在很少见。

如果您确实支持两者，不要只是让它们可以互换。与 PUT 的不同之处在于，如果它接收到一个子集，它应该假定整个内容都已上传，因此应该将默认属性应用于那些被省略的属性，或者如果需要则返回错误。而 PATCH 只会忽略那些省略的属性。

【讨论】：