我们只限于使用PUT方法来更新资源，所以PATCH不是一个选项（不幸的是）。REST API - 使用PUT方法去除属性
上下文：有些字段映射到定义为Optional和Editable的属性上，这意味着用户可以删除先前输入的和以前保存的值。
我的问题：哪个是通过PUT方法保存此更改的最佳选择？ （去除从资源属性）
AFAIK可有3个选项：
a）用一个空值，例如发送该属性。 "invoiceSerial": ""
b）发送一个清零的属性，例如： "invoiceSerial": null
三）不`吨在所有发送的属性，在服务器端，应该从存储对象中删除他们
我不能老是发现处理所有失踪编辑&可选属性任何最佳实践，所以任何暗示一些标准的文档是值得赞赏的。
选项b看起来更好，比别人：
a）用一个空值，例如发送属性。
"invoiceSerial": ""
如果invoiceSerial是一个数字怎么办？那么你会发什么？ 0？ 0对于给定的属性是一个有效值会怎么样？
b）发送一个清零的属性，例如。
"invoiceSerial": null
null是蛮好代表，以及，null值。
三）不`吨在所有发送的属性，在服务器端，应该从存储对象中删除他们
这种方法看上去更复杂，无法处理所有丢失的编辑&可选属性相比于选项b。
我不能找到任何最佳实践，所以任何暗示某些标准文档的赞赏。
我建议你先从RFC 7231
给定表示的成功PUT会建议对同一目标资源的后续GET将导致200发送的等价表示（OK ）的回应。
如果你采取这个想法，并且向后工作，你可能会得到一个合理的答案。在删除属性后，资源的表现形式如何？
这可能意味着选择（c）。
不`吨发送属性可言，而在服务器端，应该从存储的对象
消除他们处理所有失踪编辑&可选属性这里的理由是，PUT有web publishing的语义。 “使用此URI使此文档可用。”因此，您的目标是模仿支持Web创作的网站界面，将API客户与您实施的细节隔离开来。
您可能还想查看Karl Dubost汇总的链接：Understanding HTTP PUT。