幂等性是什么？
幂等性——是系统的接口对外一种承诺（而不是实现），承诺只要调用接口成功，外部多次调用对系统的影响是一致的。
一个幂等的操作典型如：把编号为5的记录的A字段设置为0，这种操作不管执行多少次都是幂等的。
一个非幂等的操作典型如：把编号为5的记录的A字段增加1，这种操作显然就不是幂等的。
要做到幂等性，从接口设计上来说不设计任何非幂等的操作即可。譬如说需求是：
当用户点击赞同时，将答案的赞同数量+1。改为：
当用户点击赞同时，确保答案赞同表中存在一条记录，用户、答案。赞同数量由答案赞同表统计出来。
HTTP幂等性是什么？
HTTP协议本身是一种面向资源的应用层协议，但对HTTP协议的使用实际上存在着两种不同的方式：一种是RESTful的，它把HTTP当成应用层协议，比较忠实地遵守了HTTP协议的各种规定；另一种是SOA的，它并没有完全把HTTP当成应用层协议，而是把HTTP协议作为了传输层协议，然后在HTTP之上建立了自己的应用层协议。本文所讨论的HTTP幂等性主要针对RESTful风格的，不过正如上一节所看到的那样，幂等性并不属于特定的协议，它是分布式系统的一种特性；所以，不论是SOA还是RESTful的Web API设计都应该考虑幂等性。下面将介绍HTTP GET、DELETE、PUT、POST四种主要方法的语义和幂等性。
1）GET
HTTPGET方法用于获取资源，不应有副作用，所以是幂等的。比如：GET http://www.bank.com/account/123456，不会改变资源的状态，不论调用一次还是N次都没有副作用。请注意，这里强调的是一次和N次具有相同的副作用，而不是每次GET的结果相同。GET http://www.news.com/latest-news这个HTTP请求可能会每次得到不同的结果，但它本身并没有产生任何副作用，因而是满足幂等性的。
2)DELETE
HTTPDELETE方法用于删除资源，有副作用，但它应该满足幂等性。比如：DELETE http://www.forum.com/article/4231，调用一次和N次对系统产生的副作用是相同的，即删掉id为4231的帖子；因此，调用者可以多次调用或刷新页面而不必担心引起错误。
3)POST
比较容易混淆的是HTTP POST和PUT。POST和PUT的区别容易被简单地误认为“POST表示创建资源，PUT表示更新资源”；而实际上，二者均可用于创建资源，更为本质的差别是在幂等性方面。POST所对应的URI并非创建的资源本身，而是资源的接收者。比如：POST http://www.forum.com/articles的语义是在http://www.forum.com/articles下创建一篇帖子，HTTP响应中应包含帖子的创建状态以及帖子的URI。两次相同的POST请求会在服务器端创建两份资源，它们具有不同的URI；所以，POST方法不具备幂等性。
4)PUT
而PUT所对应的URI是要创建或更新的资源本身。比如：PUT http://www.forum/articles/4231的语义是创建或更新ID为4231的帖子。第一次PUT方法执行之后，其在服务器上生成的资源，不能被后续的PUT方法更改，所以对同一URI进行多次PUT的副作用和一次PUT是相同的；因此，PUT方法具有幂等性。
电商应用中如何防范 POST 重复提交？
HTTP POST 操作既不是安全的，也不是幂等的（至少在HTTP规范里没有保证）。当我们因为反复刷新浏览器导致多次提交表单，多次发出同样的POST请求，导致远端服务器重复创建出了资源。
所以，对于电商应用来说，第一对应的后端 WebService 一定要做到幂等性，第二服务器端收到 POST 请求，在操作成功后必须302跳转到另外一个页面，这样即使用户刷新页面，也不会重复提交表单。
具备“幂等性”的方法是安全的，因此在程序中幂等性也是应该追求的一项性质，很多时候程序不应该假定用户的行为，不能因为用户的重复操作而导致数据出现问题。