上下文

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

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

问题

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

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

灯泡为ON。上面的代码会导致ON州。
灯泡为ON。上面的代码导致ON状态....很酷！此时，仍然保证了幂等性:-)！
灯泡为BROKEN。上述代码会导致错误，例如503 Service Unavailable

问题

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

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

，我的情况无法保证

但我也可以通过其他方式理解它：多个PUT总会导致相同的副作用：保证，我的请求要么生成转ON，要么无效（对于{{ 1}}案例，它已经存在）。

编辑：

我的意思是：唯一的副作用是将灯BROKEN转为保证（这可以保证开启或在此处不做任何操作）

< / p>

见这里：Is REST DELETE really idempotent?

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

EDIT2：

来自W3C

的定义

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

我可以认为在灯ON时转动ON是错误的吗？

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

进一步阐述： -

根据W3C（http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html），＆＃39;方法也可以具有＆＃34; idempotence＆＃34;除此之外（除错误或失效问题）N的副作用> 0个相同的请求与单个请求相同。＆＃39;

获取请求 - {＆＃39;州＆＃39;：＆＃39; ON＆＃39;} Etag-header（说） - 123 PUT请求 - {＆＃39;州＆＃39;：＆＃39; OFF＆＃39;} Etag-header - 123

某些内部活动会发生变化，以致新状态为{＆＃39;州＆＃39;：＆＃39; BROKEN＆＃39;}。在这个甚至etag应该改为124。

提出请求 - {＆＃39;州＆＃39;：＆＃39; ON＆＃39;} Etag-header - 123。由于etag标头已更改，因此返回412错误，这不会破坏api的幂等性（除了错误或过期问题）。

获取请求 - {＆＃39;州＆＃39;：＆＃39; BROKEN＆＃39;} Etag-header - 124 提出请求 - {＆＃39;州＆＃39;：＆＃39; ON＆＃39;} Etag-header - 124

并发环境中的幂等PUT

上下文

问题

问题

编辑：

EDIT2：

1 个答案: