并发环境中的幂等 PUT
Idempotent PUT in a concurrent environment
上下文
我有一个 REST API，其中多个客户端（应用程序）可以使用 PUT 更新资源的状态。例如，此资源是一个 lamp，您可以将其转为 ON 或 OFF。
当检测到发生电力故障时，该资源也会由系统自动更新，导致 lamp 处于 BROKEN 状态。我想区分BROKEN和OFF，BROKEN中的lamp不能转ON!
问题
我使用 <b>PUT</b> 方法来做到这一点，比如 <b>PUT</b> <a href="http://address:port/my_lamp" rel="nofollow noreferrer">http://address:port/my_lamp</a> { "state": "ON"}
但我不确定我是否尊重 <b>PUT</b> 方法的幂等性 属性。
事实上，我有3个案例：
- lamp 是
ON。上面的代码导致 ON 状态。
- lamp 是
ON。上面的代码导致 ON 状态....酷！这个时候还是保证幂等性的:-) !
- lamp 是
BROKEN。上面的代码会导致错误，比如 503 Service Unavailable
问题
我不确定是否正确理解幂等性的概念。相信我，我读了很多关于它的东西，但还是有点困惑。
据我了解，多个 <b>PUT</b> 总是导致相同的资源状态：由于 BROKEN
但我也可以用另一种方式理解它：多个 <b>PUT</b> 总是导致相同的副作用：保证，我的请求要么产生转向 ON，要么什么都不产生（对于 BROKEN 的情况，它已经存在）。
编辑：
我的意思是：唯一的副作用是打开 ON lamp，这是有保证的（它要么打开要么在这里什么都不做）
看这里：Is REST DELETE really idempotent?
哪个是正确的？根据理解，我的 REST API 是否确保幂等性...
EDIT2:
由W3C定义
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.
我可以认为在 BROKEN 时将 ON 变为 lamp 是错误的吗？
幂等性意味着在一个孤立的环境中，来自同一个客户端的多个请求不会对资源状态产生任何影响。如果来自另一个客户端的请求更改了资源的状态，则不会破坏幂等性原则。虽然，如果您真的想确保放置请求不会最终覆盖来自不同客户端的另一个同时请求的更改，您应该始终使用 etags。详细来说，put 请求应该始终提供最后一个资源状态的 etag（它从 get 请求中获取），并且只有当 etag 是最新的时才应该更新资源，否则应该引发 412（前提条件失败）状态代码。在 412 的情况下，客户端应该再次获取资源，然后尝试更新。根据 REST，这对于防止竞争条件至关重要。
详细说明：-
根据 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.'
Get request - {'state': 'ON'} Etag-header(say)- 123
PUT request - {'state': 'OFF'} Etag-header - 123
某些内部 activity 更改状态，使得新状态为 {'state': 'BROKEN'}。在此偶数 etag 应更改为 124.
put request - {'state': 'ON'} Etag-header - 123.
由于 etag header 已更改，返回 412 错误，这不会破坏 api 的幂等性（ 除了错误或过期问题 ）。
Get request - {'state': 'BROKEN'} Etag-header - 124
Put request - {'state': 'ON'} Etag-header - 124
上下文
我有一个 REST API，其中多个客户端（应用程序）可以使用 PUT 更新资源的状态。例如，此资源是一个 lamp，您可以将其转为 ON 或 OFF。
当检测到发生电力故障时，该资源也会由系统自动更新，导致 lamp 处于 BROKEN 状态。我想区分BROKEN和OFF，BROKEN中的lamp不能转ON!
问题
我使用 <b>PUT</b> 方法来做到这一点，比如 <b>PUT</b> <a href="http://address:port/my_lamp" rel="nofollow noreferrer">http://address:port/my_lamp</a> { "state": "ON"}
但我不确定我是否尊重 <b>PUT</b> 方法的幂等性 属性。
事实上，我有3个案例：
- lamp 是
ON。上面的代码导致ON状态。 - lamp 是
ON。上面的代码导致ON状态....酷！这个时候还是保证幂等性的:-) ! - lamp 是
BROKEN。上面的代码会导致错误，比如503 Service Unavailable
问题
我不确定是否正确理解幂等性的概念。相信我，我读了很多关于它的东西，但还是有点困惑。
据我了解，多个 <b>PUT</b> 总是导致相同的资源状态：由于 BROKEN
但我也可以用另一种方式理解它：多个 <b>PUT</b> 总是导致相同的副作用：保证，我的请求要么产生转向 ON，要么什么都不产生（对于 BROKEN 的情况，它已经存在）。
编辑：
我的意思是：唯一的副作用是打开ON lamp，这是有保证的（它要么打开要么在这里什么都不做）
看这里：Is REST DELETE really idempotent?
哪个是正确的？根据理解，我的 REST API 是否确保幂等性...
EDIT2:
由W3C定义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.
我可以认为在 BROKEN 时将 ON 变为 lamp 是错误的吗？
幂等性意味着在一个孤立的环境中，来自同一个客户端的多个请求不会对资源状态产生任何影响。如果来自另一个客户端的请求更改了资源的状态，则不会破坏幂等性原则。虽然，如果您真的想确保放置请求不会最终覆盖来自不同客户端的另一个同时请求的更改，您应该始终使用 etags。详细来说，put 请求应该始终提供最后一个资源状态的 etag（它从 get 请求中获取），并且只有当 etag 是最新的时才应该更新资源，否则应该引发 412（前提条件失败）状态代码。在 412 的情况下，客户端应该再次获取资源，然后尝试更新。根据 REST，这对于防止竞争条件至关重要。
详细说明：-
根据 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.'
Get request - {'state': 'ON'} Etag-header(say)- 123
PUT request - {'state': 'OFF'} Etag-header - 123
某些内部 activity 更改状态，使得新状态为 {'state': 'BROKEN'}。在此偶数 etag 应更改为 124.
put request - {'state': 'ON'} Etag-header - 123.
由于 etag header 已更改，返回 412 错误，这不会破坏 api 的幂等性（ 除了错误或过期问题 ）。
Get request - {'state': 'BROKEN'} Etag-header - 124
Put request - {'state': 'ON'} Etag-header - 124