什么是幂等性

HTTP/1.1中对幂等性的定义是：一次和多次请求某一个资源对于资源本身应该具有同样的结果（网络超时等问题除外）。也就是说，其任意多次执行对资源本身所产生的影响均与一次执行的影响相同。

总结来说:

1:假如第一次请求没有对资源进行修改(增加,修改,删除),那么之后的请求同样不会对资源进行修改(get获取资源)

2:假如第一次请求对资源有进行修改(增加,修改,删除),那么之后的请求只会跟第一次修改的结果一致(用户余额100,给用户增加100金额,无论请求多少次,最后余额都是为200)

3:幂等性所强调的是对资源的变更状态一致,而非返回的数据结果.

http接口中的默认幂等性

大家都知道,http协议,根据客户端请求服务端的不同操作分为多个请求方法:

GET    /users      # 获取users列表
GET    /users/12    # 查看某个具体的users
POST   /users      # 新建一个users
PUT    /users/12    # 更新users 12
DELETE  /users/12    # 删除users 12

get 方法(幂等)

get方法对资源并没有任何的影响,虽然第一次请求完,可能会有数据更改(并非这次请求的修改),获取的数据和第一次的不一致,但并不是它修改的数据,所以它在http协议中默认是幂等性的操作

post 方法(非幂等)

大家都知道,post一般用于提交表单,新增或修改数据,当提交多次时,会新增多次数据,所以它默认情况是非幂等性操作.

put方法(幂等)

put方法将替换原有的资源,由于是直接替换,无论多少次请求,替换的内容都是相同的,所以它是幂等性操作

delete方法(幂等)

delete针对于删除某一个资源,再次删除的话并不会额外删除其他的资源,也不会新增资源,所以它是幂等性操作

幂等性应用场景

在上面的http默认幂等性中,我们可以看出,post方法是非幂等性的(当然不止post一个).而且,在我们正常后端写接口时,用的最多的应该是post/get去实现所有的数据操作方式.那么,现在有一些问题:

用户A提交一个支付订单,由于添加时网络不好,用户点击了2次.

那么接口正常来说,是会新增2个订单的,但是这样就会严重影响用户的体验了

同理

用户A想给B转账100元钱,但是不小心点了2下,如果没做好幂等性,就会造成扣除2次100,扣200块钱.

支付宝支付请求服务器充值回调,给用户A增加余额,同时给支付宝返回OK告诉支付宝增加余额成功,但由于网络异常,支付宝没有收到OK信号,给服务器重发了一次充值回调,这时候给用户A又增加了一次余额

从上面的例子可以看出,当多次提交会影响体验甚至账户安全的情况下,都应该增加幂等性操作

那么,接口幂等性该怎么做呢?

接口实现幂等性

防重复提交

在上面的例子可以看出,