REST - 修改资源的一部分 - PUT或POST

我正在看到如何使用REST更新资源的一部分(例如状态指示器)的主题.

选项似乎是:

抱怨HTTP没有PATCH或MODIFY命令.但是,对于REST的HTTP MODIFY动词,接受的答案是什么？能很好地展示为什么这不像看起来那么好.

将POST与参数一起使用并识别方法(例如,名为"action"的参数).一些建议是使用自定义方法名称指定X-HTTP-Method-Override标头.这似乎导致了基于你正在尝试做的事情在实现中切换的丑陋,并且批评不是一种特别的REST方式来使用POST.事实上,采用这种方法开始感觉像RPC类型的接口.

使用PUT覆盖资源的子资源,该子资源表示要更新的特定属性.实际上,这实际上是对子资源的重写,这似乎符合PUT的精神.

在这一点上,我认为#3是最合理的选择.

这是最佳做法还是反模式？还有其他选择吗？

有两种方法可以查看状态更新.

更新到一个东西.这是一个PUT.选项3

在事物的历史记录中添加其他日志条目.此序列日志条目中的列表项是当前状态.这是一个POST.选项2.

如果您是数据仓库或函数式编程类型,那么您往往会对状态更改不信任,并且喜欢将一段新的历史事实POST到静态的,不可变的事物中.这确实需要将事物与事物的历史区分开来; 导致两张桌子.

否则,你不介意改变事物状态的"更新",你对PUT感到满意.这不区分事物和它的历史,并将所有内容保存在一个表中.

就个人而言,我发现我越来越不信任可变对象和PUT(除了"纠错").(即使在那时,我认为旧的东西可以留在原地,新的东西添加了对自己的先前版本的引用.)

如果状态发生变化,我认为应该有一个状态日志或历史记录,并且应该有一个POST来为该历史记录添加新条目.可能会有一些优化来反映适用对象的"当前"状态,但这只是幕后优化.

选项3(PUT到一些独立的子资源)是你现在最好的选择,并且在主要资源本身上使用POST不一定是"错误的" - 尽管你可能不同意这取决于你想要的迂腐程度关于它.

坚持3并使用更细粒度的子资源,如果你确实需要类似PATCH的行为 - 使用POST.就个人而言,即使PATCH确实最终成为一个可行的选择,我仍然会使用这种方法.

HTTP 确实有PATCH命令.它在RFC 2068的第19.6.1.1节中定义,并在draft-dusseault-http-patch-16中更新,目前正在等待作为RFC发布.