Question

我很难理解为什么PAT在PUT不安全的地方。也就是幂等部分 - 如果我更新资源的一个字段，那么该字段在更新后是否会返回相同的值？

Answer 1

这不是安全，因为通常来说，如果不更改资源就无法安全地执行PATCH请求（这就是它的目的）。

那为什么与PUT相比PATCH不具有幂等？这是因为您应用更改很重要。如果您想更改资源的name属性，则可以发送{"name": "foo"}之类的内容作为有效负载，这实际上是幂等的，因为多次执行此请求都会产生相同的结果：资源name属性现在为“ foo”。

但是PATCH在更改资源的方式上更为通用（请检查this定义如何应用JSON补丁）。例如，它也可能意味着移动资源，并且看起来像这样：{ "op": "move", "from": "/a/b/c", "path": "/a/b/d" }。显然，此操作不是幂等的，因为第二次调用会导致错误。

因此，尽管大多数PATCH操作可能是幂等的，但有些却不是。

对其他答案的一个评论：幂等性是通过连续多次重复操作来定义的。说某事不是幂等的，因为如果在两者之间或并行执行某些其他操作的结果是不同的，那将不是有效的参数（如果是这种情况，则一般而言，任何操作都不是幂等的）。从数学上讲，幂等变换是一种结果相同的结果，而不管您应用它的频率如何（例如旋转360度）。当然，如果在两者之间进行任何其他操作，则两次360度旋转可能会产生不同的结果。

Answer 2

PATCH更改资源属性。更改可能需要属性的具体先前值，这使其成为非幂等的。

<ButtonCanvas {...this.state} />

重复申请后，名字将是Gargantua，补丁将失败，因为它要求名称为＆＃34; John＆＃34;在改变之前

From Name=John to Name=Gargantua.

Answer 3

我最近开始查看Patch是否是等幂的，并且在阅读了有关JSON补丁格式的信息之后，我了解到，如果使用Patch方法应用添加操作，则完全有可能该请求是非等幂的，因为它可以添加如果多次发出相同的请求，则会为现有资源添加新值。

{“ op”：“ add”，“ path”：“ / a / b / c”，“ value”：[“ foo”，“ bar”]}

Answer 4

首先，PUT也不安全。

安全方法是不修改资源的HTTP方法。例如，在资源URL上使用GET或HEAD，不应该更改资源。

由于PUT请求（因此PATCH也是如此）更新资源，因此无法缓存，因此它不是安全的。

PUT请求虽然是幂等的，或者我应该说PUT请求应该是幂等的。

幂等HTTP方法是一种HTTP方法，可以多次调用而不会产生不同的结果。如果只调用一次或十次调用该方法，则无关紧要。结果应该是一样的。同样，这仅适用于结果，而不适用于资源本身。这仍然可以被操作（如更新时间戳，只要此信息不在（当前）资源表示中共享。

PUT请求为幂等的背后的想法是，如果对资源的更新调用失败，则客户端可以再次进行相同的调用，而不会导致任何不良或不一致的状态。 PUT请求之前应始终对资源发出GET请求，并且如果此后资源没有更改，则应该成功。详细说明： - 通过一个类似的答案 - Idempotent PUT request in concurrent environment

现在PATCH请求仅用于更新选择性字段，预计不会获取资源表示。因此，对PATCH请求的多次调用可能最终导致资源状态的不良变化。因此它不是IDEMPOTENT。

例如： - 有资源Person

请求1： PATCH / person / 1 {'age'：10} - 将资源年龄更新为10

现在假设其他一些并行请求改变了资源状态，比如说

请求2： PATCH / person / 1 {'age'：19} - 将资源年龄更新为19

现在，如果再次发送请求1，它会再次将资源年龄更新为10，从而导致不良结果。

虽然使用etags或If Modified Since标题，但它可以是幂等的。

为什么PATCH既不安全也不幂等？

4 个答案: