什么是幂等性
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又增加了一次余额
从上面的例子可以看出,当多次提交会影响体验甚至账户安全的情况下,都应该增加幂等性操作
那么,接口幂等性该怎么做呢?
接口实现幂等性
防重复提交
在上面的例子可以看出,有时候主要问题在于,客户端点了2下,那么我们可以通过客户端请求进行限制.
客户端防止重复提交
新增一个变量isSubmit,当点击请求后,判断isSubmit为0才允许提交数据,并更新为1,等待请求结束后改为0,确保该请求每次只能点击一次.通常为了防止重复提交,客户端在点击后都会出现一个加载动画,防止用户继续点击.
服务端发放token防止重复提交
当客户端需要提交表单时,需要先向服务端请求一个有效的token,该token有着时效性和一次性,提交完或者过期都将失效,客户端提交表单时附带token,再次提交token将失效,无法继续提交.
唯一标识幂等
例如,当用户需要申请添加某一位用户作为好友,当发起申请时,理应新增一条申请消息,再次发起后.
可通过用户id进行查询数据库是否存在一条同样的好友申请,如果存在,则不新增,直接返回原有数据
这个例子可以看出,只要你提交的数据,具有唯一性,即可通过此唯一性进行数据库判定,如果存在该数据,则不产生操作,直接返回原有数据.
注:阿里云Oss新增bucket时采用了此方法,bucket名称唯一,可以一直调用新增bucket,但不会出现多条数据
