最近遇到接口幂等性的坑，总结了一下

当接口的入参已经不满足操作条件时则返回不可执行的结果
这个要求的目的是什么呢，没跟上思路

@pi1ot 可能是我说的不清楚。
比如博客里面用到的订单系统为例：一个操作要求把订单 orderStatus 变更为 1 ，对于订单系统而言，这个操作可以成功的前提是 orderStatus=0,其实也就是把 orderStatus 0->1 的操作。但是因为 orderStatus 是一个流转中的状态，请求操作是 orderStatus=2 了，那这个操作就应该失败了。

前面同意。
最后说的
》 3.2 接口局部状态幂等性
这个，不太同意。

ps ：我觉得，这里，幂等性的限制，你是加载 orderId 上。然后因为有了 orderStatus ，结果某些时候，幂等性不成立了。你可以考虑，加上一个 uuid ，保证 uuid 的幂等性。当然，也会有 orderStatus 的问题，但是，那不是幂等性需要考虑的。不知道我表达清楚没？

@mahone3297 嗯，说的有道理。我在写这部分的时候也觉得这样划分幂等性是不是有问题， orderStatus 参杂了多个业务逻辑在里面。 你说的 uuid 是指将 orderStatus 0->1(状态变更)时的唯一标识？也就说只要 uuid 操作过了，后面再操作就直接返回？

我之前考虑过“局部状态幂等性”，觉得是个好的概念。幂等性应该不是返回相同的结果，而是对系统的副作用相同，比如 orderStatus 的变更，这里的副作用是不是应该是 orderStatus 的正确转换。

@brucefeng 我这边 uuid ，你也可以理解成 requestId ，反正一个请求 1 个 id ，而且是唯一的。
幂等性需要保证的，就是，这个请求，从 a 发往 b 的过程中，保证发过了，并且 b 回复说收到了。其与订单什么的，可以没有任何关系。

@brucefeng 幂等性，只保证， a 发给 b 的消息，发了，并且 b 收到了，并且 a 如果多发，也不会有副作用。其实也就是幂等性的定义。
所以，至于什么订单状态变了啊，订单如何了啊，我们前面讨论的幂等性（基于 uuid or requestId ），根本不在乎。

@mahone3297 但是幂等性是指多次调用对系统的副作用是相同的， a 发往 b ， b 回复收到了，这个算不上对系统相同的副作用。应该是 a 调用 b 让 b 做一件事情， b 返回给 a 成功了 才是幂等性。

为啥不用 Compare and Swap 去做呢？把状态表现层化就好了。