并发环境中的幂等PUT [英] Idempotent PUT in a concurrent environment

问题描述

我有一个REST API，其中多个客户端（应用程序）可以使用PUT更新资源的状态。例如，此资源是一盏灯，您可以将 ON 或 OFF 。

I have a REST API where multiple clients (applications) can update the state of a resource with PUT. For the example, this resource is a lamp that you can turn ON or OFF.

当系统检测到发生电力故障时，该资源也会自动更新，导致灯泡处于 BROKEN 状态。我想区分 BROKEN 和 OFF ， BROKEN 无法转 ON ！

This resource is also automatically updated by the system when it detects that an electricity failure has occurs, leading to have a lamp in a BROKEN state. I want to made the distinction between BROKEN and OFF, a lamp in BROKEN can not be turn ON !

我使用 PUT 方法执行此操作，例如 PUT http：// address：port / my_lamp {state：ON}

I use PUT method to do this, something like PUT http://address:port/my_lamp { "state": "ON"}

但我不确定我是否尊重 PUT 方法的幂等属性。
事实上，我有3个案例：

But I am not sure if i respect the idempotent property of PUT method. In fact, i have 3 cases:

• 灯泡是 ON 。上面的代码导致 ON 状态。


• 灯是 ON 。上面的代码导致 ON 状态....很酷！此时，仍然保证幂等性:-)！


• 灯泡是 BROKEN 。上面的代码会导致错误，例如 503服务不可用

• The lamp is ON. The above code leads to the ON state.
• The lamp is ON. The above code leads to the ON state.... cool! At this moment, idempotency is still guaranteed :-) !
• The lamp is BROKEN. The above code leads to an error, like 503 Service Unavailable

我不确定正确理解幂等性的概念。相信我，我读了很多关于它的事情，但仍然有点困惑。

I am not sure to correctly understand the notion of idempotency. Trust me, I read a lot of thing about it but still a little bit confused.

根据我的理解，多个 PUT 总是导致资源的相同状态：由于 BROKEN

In my understanding, multiple PUT always leads to a same state of the resource: not guaranteed in my case due to BROKEN

但我也可以通过其他方式理解它：多个 PUT 总会导致相同的副作用：保证，我的请求生成转 ON ，或者什么都没有（对于 BROKEN 情况，它已经存在）。

编辑：

我的意思是：唯一的副作用是将灯泡转换为 ON ，这是保证的（它要么开启了或者在这里什么都不做）

But I could also understand it in an other way: multiple PUT always leads to the same side-effect: guaranteed, my request either produce to turn ON, either nothing (for the BROKEN case, it was already in).

I mean: the only side-effect is to turn ON the lamp, which is guaranteed (it either turn-on or do nothing here)

见这里： REST DELETE真的是幂等的吗？

哪一个是正确的？根据理解，我的REST API确保是否具有幂等性......

Which one is correct ? Depending of the understanding, my REST API ensure idempotency or not...

EDIT2：

来自 W3C

方法也可以具有幂等的属性（除了错误或过期问题）N> 0个相同请求的副作用与单个请求相同。

Methods can also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request.

我可以认为将灯泡变为 ON 是一个错误 BROKEN ？

Can i consider that it's an error to turn ON the lamp when it is BROKEN ?

推荐答案

幂等性意味着在隔离环境中，来自同一客户端的多个请求对资源状态没有任何影响。如果来自另一个客户端的请求改变了资源的状态，那么它不会破坏幂等性原则。虽然，如果您确实希望确保put请求不会最终通过来自不同客户端的另一个同时请求覆盖更改，则应始终使用etags。详细说明，put请求应始终提供最后一个资源状态的etag（它来自get请求），并且只有当etag是最新的时才应更新资源，否则应该引发412（Precondition Failed）状态代码。在412的情况下，客户端假设再次获取资源，然后尝试更新。根据REST，这对于防止竞争条件至关重要。

Idempotency means that in an isolated environment multiple requests from a same client does not have any effect on the state of resource. If request from another client changes the state of the resource, than it does not break the idempotency principle. Although, if you really want to ensure that put request does not end up overriding the changes by another simultaneous request from different client, you should always use etags. To elaborate, put request should always supply an etag (it got from get request) of the last resource state, and only if the etag is latest the resource should be updated, otherwise 412 (Precondition Failed) status code should be raised. In case of 412, client is suppose to get the resource again, and then try the update. According to REST, this is vital to prevent race conditions.

详细说明： -

根据W3C（ http://www.w3.org/Protocols/rfc2616/rfc2616-sec9 .html ），'方法也可以具有幂等的属性（除了错误或过期问题）N> 0个相同请求的副作用是相同的对于单个请求。'

According to W3C(http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html), 'Methods can also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request.'

获取请求 - {'state'：'ON'} Etag-header（比如说） - 123
PUT请求 - {' state'：'OFF'} Etag-header - 123

Get request - {'state': 'ON'} Etag-header(say)- 123 PUT request - {'state': 'OFF'} Etag-header - 123

某些内部活动会更改状态，以便新状态为{'state'：'BROKEN'}。在这个甚至etag应改为124.

Some internal activity changes state such that new state is {'state': 'BROKEN'}. In this even etag should be changed to say 124.

put request - {'state'：'ON'} Etag-header - 123.
自etag以来标头已更改，返回412错误，不会破坏api的幂等性（除了错误或过期问题）。

put request - {'state': 'ON'} Etag-header - 123. Since etag header has changed, 412 error is returned which does not break idempotence of api (aside from error or expiration issues).

获取请求 - { 'state'：'BROKEN'} Etag-header - 124
Put request - {'state'：'ON'} Etag-header - 124

Get request - {'state': 'BROKEN'} Etag-header - 124 Put request - {'state': 'ON'} Etag-header - 124

这篇关于并发环境中的幂等PUT的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！