REST API修补程序请求预期行为

Patch 操作应该是原子的,根据 the spec :

服务器必须以原子方式应用整个更改集,而且永远不会 部分修改的表示。如果整个补丁文件 这些变化。什么是成功的决定 正在修改的资源。例如,公共“diff”实用程序 可以生成一个修补程序文档,该文档应用于一个应用程序中的多个文件 目录层次结构。原子性要求对所有人都适用 直接影响的文件。请参阅“错误处理”, Section 2.2 ,用于 有关状态代码和可能的错误情况的详细信息。

看来你的案子

不可处理的请求:可以用422(不可处理的 (实体)响应( [RFC4918], Section 11.2 文档似乎有效,但服务器无法 使资源失效的方式; 将导致它不再是良好的形式。也可能有 一般来说,你会更有帮助。

一 409 Conflict 也可能是适当的,这取决于无法修改资源的原因。

我是这么想的 un_updateable_field

你可以选择忽略它,也可以选择抛出一个错误。你该做什么取决于你自己。我更喜欢我的系统是严格的,而不是忽略无效值,因为如果出现无效值,它可能表明您在某个地方有一个错误,最好得到一个硬错误,这样您就可以修复这个错误。