我有一个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确保了幂等性......
的定义
方法也可以具有“幂等性”的特性（除了错误或期满问题）N的副作用> 0个相同的请求与单个请求相同。
我可以认为在灯ON时转动ON是错误的吗？
答案 0 :(得分：7)
幂等性意味着在隔离环境中，来自同一客户端的多个请求对资源状态没有任何影响。如果来自另一个客户端的请求改变了资源的状态，那么它不会破坏幂等性原则。虽然，如果您确实希望确保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