理解http的幂等性

幂等性是什么?

幂等性——是系统的接口对外一种承诺(而不是实现),承诺只要调用接口成功,外部多次调用对系统的影响是一致的。
一个幂等的操作典型如:把编号为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跳转到另外一个页面,这样即使用户刷新页面,也不会重复提交表单。

具备“幂等性”的方法是安全的,因此在程序中幂等性也是应该追求的一项性质,很多时候程序不应该假定用户的行为,不能因为用户的重复操作而导致数据出现问题。

原文地址:https://www.cnblogs.com/gyjjyg/p/9855511.html

时间: 2024-10-09 12:15:41

理解http的幂等性的相关文章

理解HTTP幂等性

基于HTTP协议的Web API是时下最为流行的一种分布式服务提供方式.无论是在大型互联网应用还是企业级架构中,我们都见到了越来越多的SOA或RESTful的Web API.为什么Web API如此流行呢?我认为很大程度上应归功于简单有效的HTTP协议.HTTP协议是一种分布式的面向资源的网络应用层协议,无论是服务器端提供Web服 务,还是客户端消费Web服务都非常简单.再加上浏览器.Javascript.AJAX.JSON以及HTML5等技术和工具的发展,互联网应用架构设 计表现出了从传统的P

#HTTP协议学习# (十一)理解HTTP幂等性

在httpcomponent 文档中看到如下段落: 1.4.1. HTTP transport safety It is important to understand that the HTTP protocol is not well suited to all types of applications. HTTP is a simple request/response oriented protocol which was initially designed to support s

[转]理解HTTP幂等性

基于HTTP协议的Web API是时下最为流行的一种分布式服务提供方式.无论是在大型互联网应用还是企业级架构中,我们都见到了越来越多的SOA或RESTful的Web API.为什么Web API如此流行呢?我认为很大程度上应归功于简单有效的HTTP协议.HTTP协议是一种分布式的面向资源的网络应用层协议,无论是服务器端提供Web服务,还是客户端消费Web服务都非常简单.再加上浏览器.Javascript.AJAX.JSON以及HTML5等技术和工具的发展,互联网应用架构设计表现出了从传统的PHP

幂等性 个人理解及应用

绝大部分网络上对幂等性的解释类似于: "幂等性是指重复使用同样的参数调用同一方法时总能获得同样的结果.比如对同一资源的GET请求访问结果都是一样的." 我认为这种解释是非常错误的, 幂等性强调的是外界通过接口对系统内部的影响, 外界怎么看系统和幂等性没有关系. 就上面这种解释, System.getCPULoad(), 这两次调用返回能一样吗? 但因为是只读接口, 对系统内部状态没有影响, 所以这个函数还是幂等性的. 首先了解一下什么是幂等性,如果你没有兴趣可以直接跳过这段代数概念解释

理解HTTP幂等性(转)

基于HTTP协议的Web API是时下最为流行的一种分布式服务提供方式.无论是在大型互联网应用还是企业级架构中,我们都见到了越来越多的SOA或RESTful的Web API.为什么Web API如此流行呢?我认为很大程度上应归功于简单有效的HTTP协议.HTTP协议是一种分布式的面向资源的网络应用层协议,无论是服务器端提供Web服 务,还是客户端消费Web服务都非常简单.再加上浏览器.Javascript.AJAX.JSON以及HTML5等技术和工具的发展,互联网应用架构设 计表现出了从传统的P

深入理解幂等性

什么是幂等性 HTTP/1.1中对幂等性的定义是:一次和多次请求某一个资源对于资源本身应该具有同样的结果(网络超时等问题除外).也就是说,其任意多次执行对资源本身所产生的影响均与一次执行的影响相同. Methods can also have the property of “idempotence” in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is th

深入理解Oracle RAC 12c

深入理解Oracle RAC 12c(顶尖专家权威指南唯一最新版数据库著作 Oracle第一社区技术大牛翻译 Amazon五星推荐) [美]Syed Jaffar Hussain(赛义德 贾法尔 侯赛因),Tariq Farooq(塔里克 法鲁克),Riyaj Shamsudeen(瑞亚吉沙姆斯丁),Kai Yu(于凯) 著   赵燚 梁涛 程飞 李真旭 译 ISBN 978-7-121-24066-9 2014年10月出版 定价:99.00元 488页 16开 编辑推荐 <深入理解 Oracl

HTTP幂等性简单了解

基于HTTP协议的Web API是时下最为流行的一种分布式服务提供方式.无论是在大型互联网应用还是企业级架构中,我们都见到了越来越多的SOA或RESTful的Web API.为什么Web API如此流行呢?我认为很大程度上应归功于简单有效的HTTP协议.HTTP协议是一种分布式的面向资源的网络应用层协议,无论是服务器端提供Web服务,还是客户端消费Web服务都非常简单.再加上浏览器.Javascript.AJAX.JSON以及HTML5等技术和工具的发展,互联网应用架构设计表现出了从传统的PHP

Raft 为什么是更易理解的分布式一致性算法——(1)Leader在时,由Leader向Follower同步日志 (2)Leader挂掉了,选一个新Leader,Leader选举算法。

转自:http://www.cnblogs.com/mindwind/p/5231986.html Raft 协议的易理解性描述 虽然 Raft 的论文比 Paxos 简单版论文还容易读了,但论文依然发散的比较多,相对冗长.读完后掩卷沉思觉得还是整理一下才会更牢靠,变成真正属于自己的.这里我就借助前面黑白棋落子里第一种极简思维来描述和概念验证下 Raft 协议的工作方式. 在一个由 Raft 协议组织的集群中有三类角色: Leader(领袖) Follower(群众) Candidate(候选人