我不确定以下场景的预期行为是什么:
补丁请求 1:
"body": {
"un_updatable_field" : "data"
}
所以在这里我只是抛出一个异常:Field cannot be updated
,无论如何。
补丁请求 2:
"body": {
"all_required_fields" : "all",
"un_updatable_field" : "data"
}
我应该在这里做什么?抛出异常并且不更新模型?
我不确定以下场景的预期行为是什么:
补丁请求 1:
"body": {
"un_updatable_field" : "data"
}
所以在这里我只是抛出一个异常:Field cannot be updated
,无论如何。
补丁请求 2:
"body": {
"all_required_fields" : "all",
"un_updatable_field" : "data"
}
我应该在这里做什么?抛出异常并且不更新模型?
Patch
根据规范,操作应该是原子的:
服务器必须以原子方式应用整个更改集,并且从不提供(例如,在此操作期间响应 GET)部分修改的表示。如果无法成功应用整个补丁文档,则服务器不得应用任何更改。根据补丁文档和正在修改的资源类型,确定什么是成功的 PATCH 可能会有所不同。例如,常见的“diff”实用程序可以生成适用于目录层次结构中多个文件的补丁文档。原子性要求适用于所有直接受影响的文件。有关状态代码和可能的错误条件的详细信息,请参见第 2.2 节的“错误处理” 。
看起来你的具体情况是
无法处理的请求:当服务器理解补丁文档并且补丁文档的语法似乎有效但服务器无法处理请求时,可以使用 422(不可处理实体)响应([RFC4918],第 11.2 节)指定. 这可能包括尝试以导致资源无效的方式修改资源;例如,对格式良好的 XML 文档的修改将导致其不再是格式良好的。也可能有更具体的错误,如“冲突状态”,可以使用此状态代码发出信号,但更具体的错误通常会更有帮助。
a409 Conflict
也可能是合适的,具体取决于无法修改资源的原因。
我假设这un_updateable_field
是您系统中存在的一个字段,但您不想让人们更新它。
您可以选择忽略它,也可以选择抛出错误。你应该做什么取决于你。我更喜欢我的系统是严格的,而不是忽略无效值,因为如果出现无效值,它可能表明你在某个地方有一个错误,最好得到一个硬错误,这样你就可以修复这个错误。