api - 并发环境中的幂等 PUT

Question

上下文

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

当检测到发生电力故障时，系统也会自动更新此资源，导致在 BROKEN 中有一盏灯。状态。我想区分 BROKEN和 OFF , 一盏灯 BROKEN不能转ON !

问题

我使用 <b>PUT</b>方法来做到这一点，类似于<b>PUT</b> <a href="http://address:port/my_lamp" rel="noreferrer noopener nofollow">http://address:port/my_lamp</a> { "state": "ON"}

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

• 灯是ON .上面的代码导致 ON状态。
• 灯是ON .上面的代码导致 ON状态....酷!此时，幂等性还是有保证的:-) !
• 灯是BROKEN .上面的代码会导致错误，例如 503 Service Unavailable

问题

我不确定是否正确理解幂等性的概念。相信我，我读了很多关于它的东西，但还是有点困惑。

据我了解，多个 <b>PUT</b>总是导致相同的资源状态:由于 BROKEN 在我的情况下无法保证

但我也可以用另一种方式理解它:多个 <b>PUT</b>总是导致相同的副作用:保证，我的要求要么产生转向ON ，要么什么都没有(对于 BROKEN 案例，它已经存在)。

编辑:

我的意思是:唯一的副作用是转 ON灯，这是有保证的(它要么打开要么在这里什么都不做)

参见此处: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.

我可以认为转 ON 是错误的吗？灯是BROKEN ？

Answer 1

幂等性意味着在隔离环境中，来自同一客户端的多个请求不会对资源状态产生任何影响。如果来自另一个客户端的请求更改了资源的状态，则不会破坏幂等性原则。虽然，如果您真的想确保放置请求不会最终覆盖来自不同客户端的另一个同时请求的更改，您应该始终使用 etags。详细来说，put 请求应该始终提供最后一个资源状态的 etag(它从 get 请求中获取)，并且只有当 etag 是最新的时才应该更新资源，否则应该引发 412(前提条件失败)状态代码。在 412 的情况下，客户端应该再次获取资源，然后尝试更新。根据 REST，这对于防止竞争条件至关重要。

详细说明:-

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

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

某些内部事件更改状态，使得新状态为 {'state': 'BROKEN'}。在此 even 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