我们只能使用 PUT 方法来更新资源,因此 PATCH 不是一个选项(不幸的是)。
上下文:在某些情况下,映射到属性上的字段被定义为可选和可编辑,这意味着用户可以删除先前输入和先前保存的值。
我的问题:通过 PUT 方法保存此更改的最佳选项是什么? (从资源中删除属性)
据我所知,有 3 个选项可用:
a) 发送带有空值的属性,例如。
"invoiceSerial": ""
b) 发送带有明确空值的属性,例如。
"invoiceSerial": null
c)根本不发送属性,并且在服务器端,它应该通过从存储的对象中删除它们来处理所有丢失的可编辑和可选属性
我找不到任何最佳实践,因此对某些标准文档的任何提示表示赞赏。
选项 b 与其他选项相比看起来更好:
a) 发送带有空值的属性,例如。
"invoiceSerial": ""
如果
invoiceSerial
是一个数字怎么办?那你会送什么? 0
?如果 0
是给定属性的有效值怎么办?
b) 发送带有明确空值的属性,例如。
"invoiceSerial": null
null
可以很好地表示 null
值。
c)根本不发送属性,并且在服务器端,它应该通过从存储的对象中删除它们来处理所有丢失的可编辑和可选属性
与选项 b 相比,此方法看起来实施起来更复杂。
我找不到任何最佳实践,因此对某些标准文档的任何提示表示赞赏。
我建议您从RFC 9110
开始给定表示的成功 PUT 表明对同一目标资源的后续 GET 将导致在 200(OK)响应中发送等效的表示。
如果你接受这个想法,并逆向思考,你可能会得到一个合理的答案。删除属性后,资源的表示形式是什么样的?
这可能意味着选择 (c)。
根本不发送属性,并且在服务器端,它应该通过从存储的对象中删除它们来处理所有丢失的可编辑和可选属性
这里的理由是 PUT 具有网络发布的语义。 “使用此 URI 使此文档可用。”因此,您的目标是模仿支持 Web 创作的网站界面,将 api 使用者与您的实现细节隔离开来。
您可能还想查看 Karl Dubost 聚合的链接:了解 HTTP PUT。