这是一个创建于 3376 天前的主题，其中的信息可能已经有所发展或是发生改变。
也是节前工作量小写的。
 |
1
pi1ot 2015-09-30 11:35:42 +08:00
当接口的入参已经不满足操作条件时则返回不可执行的结果
这个要求的目的是什么呢，没跟上思路 |
 |
2
brucefeng OP @pi1ot 可能是我说的不清楚。
比如博客里面用到的订单系统为例：一个操作要求把订单 orderStatus 变更为 1 ，对于订单系统而言，这个操作可以成功的前提是 orderStatus=0,其实也就是把 orderStatus 0->1 的操作。但是因为 orderStatus 是一个流转中的状态，请求操作是 orderStatus=2 了，那这个操作就应该失败了。 |
 |
3
mahone3297 2015-09-30 11:53:14 +08:00
前面同意。
最后说的 》 3.2 接口局部状态幂等性 这个，不太同意。 ps ：我觉得，这里，幂等性的限制，你是加载 orderId 上。然后因为有了 orderStatus ，结果某些时候，幂等性不成立了。你可以考虑，加上一个 uuid ，保证 uuid 的幂等性。当然，也会有 orderStatus 的问题，但是，那不是幂等性需要考虑的。不知道我表达清楚没？ |
|
4
brucefeng OP @mahone3297 嗯，说的有道理。我在写这部分的时候也觉得这样划分幂等性是不是有问题， orderStatus 参杂了多个业务逻辑在里面。 你说的 uuid 是指将 orderStatus 0->1(状态变更)时的唯一标识？也就说只要 uuid 操作过了，后面再操作就直接返回？
我之前考虑过“局部状态幂等性”，觉得是个好的概念。幂等性应该不是返回相同的结果，而是对系统的副作用相同，比如 orderStatus 的变更，这里的副作用是不是应该是 orderStatus 的正确转换。 |
|
5
mahone3297 2015-09-30 14:16:51 +08:00  1
@brucefeng 我这边 uuid ，你也可以理解成 requestId ，反正一个请求 1 个 id ，而且是唯一的。
幂等性需要保证的，就是，这个请求，从 a 发往 b 的过程中，保证发过了，并且 b 回复说收到了。其与订单什么的，可以没有任何关系。 |
|
6
mahone3297 2015-09-30 14:19:02 +08:00
@brucefeng 幂等性，只保证， a 发给 b 的消息，发了，并且 b 收到了，并且 a 如果多发，也不会有副作用。其实也就是幂等性的定义。
所以，至于什么订单状态变了啊，订单如何了啊，我们前面讨论的幂等性（基于 uuid or requestId ），根本不在乎。 |
|
7
brucefeng OP @mahone3297 但是幂等性是指多次调用对系统的副作用是相同的， a 发往 b ， b 回复收到了，这个算不上对系统相同的副作用。应该是 a 调用 b 让 b 做一件事情， b 返回给 a 成功了 才是幂等性。
|
 |
8
JamesRuan 2015-10-01 00:23:02 +08:00
为啥不用 Compare and Swap 去做呢？把状态表现层化就好了。
|
Select Language