假设我有一个名为Person的资源。我可以通过Person到POST更新/data/Person/{ID}个实体。假设一个人有三个属性，名字，姓氏和年龄。
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允许您来回发送大量数据，即使它没有改变，也没有告诉服务器这个有效负载真正重要的是什么（只有年龄改变了）。
答案 0 :(得分：3)
选项1 - 更新资源的子集 - 现在在HTTP中形式化为PATCH方法。选项2 - 更新整个资源 - 是PUT方法。
在实际场景中，通常只想上传资源的子集。这对于请求的性能和客户的模块化/多样性更好。
因此，在典型的API（imo）中，PATCH现在比PUT更有用，但如果你愿意，你可以支持两者。有一些极端情况，平台可能不支持PATCH，但我相信它们现在很少见。
如果你同时支持它们，不要只是让它们可以互换。与PUT的不同之处在于，如果它接收到一个子集，它应该假设整个事物被上传，那么应该将默认属性应用于那些被省略的属性，或者如果需要则返回错误。而PATCH只会忽略那些省略的属性。