HTTP方法中，哪个操作不是幂等的

HTTP协议及其POST与GET操作差异 & C#中如何使用POST、GET等

2010-05-18 15:29 by 吴秦, 53218 阅读, 81 评论, 收藏, 编辑

引言

HTTP协议我想任何IT人士都耳熟能详了，大家都能说出个所以然来。但是如果我问你HTTP协议的请求方法有哪些？POST与GET的差异？GET或POST传送数据量的大小有限制吗？HTTP响应的状态有哪些？以及在C#中你如何使用？如果你不能清楚地回答其中的大部分问题，那么这篇文章就是为你准备的！大纲如下：

• 1、HTTP概述
  • 1.1、HTTP协议的客户端与服务器的交互
  • 1.2、HTTP消息
  • 1.3、HTTP请求的方法
  • 1.4、HTTP响应的代码
• 2、抓包分析
• 3、POST与GET的差异
• 4、以一个实例说明C#中如何使用POST、GET等操作
  • 4.1、HttpWebRequest
  • 4.2、HttpWebResponse
  • 4.3、编写WinForm程序打开博客园首页（附源码）

1、HTTP概述

为了唤醒你对HTTP协议的记忆或使你能够对HTTP协议有所了解，首先简单一下HTTP协议。超文本传输协议（HTTP，HyperText Transfer Protocol）是互联网上应用最为广泛的一种网络协议。所有的WWW文件都必须遵守这个标准。设计HTTP最初的目的是为了提供一种发布和接收HTML页面的方法。

HTTP的发展是万维网协会（World Wide Web Consortium）和Internet工作小组（Internet Engineering Task Force）合作的结果，（他们）最终发布了一系列的RFC，其中最著名的就是RFC 2616。RFC 2616定义了HTTP协议中一个现今被广泛使用的版本——HTTP 1.1。

1.1、HTTP协议的客户端与服务器的交互

HTTP是一个客户端和服务器端请求和应答的标准（TCP）。客户端是终端用户，服务器端是网站。通过使用Web浏览器、网络爬虫或者其它的工具，客户端发起一个到服务器上指定端口（默认端口为80）的HTTP请求。（我们称这个客户端）调用户代理（user agent）。应答的服务器上存储着（一些）资源，比如HTML文件和图像。（我们称）这个应答服务器为源服务器（origin server）。在用户代理和源服务器中间可能存在多个中间层，比如代理，网关，或者隧道（tunnel）。尽管TCP/IP协议是互联网上最流行的应用，HTTP协议并没有规定必须使用它和（基于）它支持的层。事实上，HTTP可以在任何其他互联网协议上，或者在其他网络上实现。HTTP只假定（其下层协议提供）可靠的传输，任何能够提供这种保证的协议都可以被其使用。

通常，由HTTP客户端发起一个请求，建立一个到服务器指定端口（默认是80端口）的TCP连接。HTTP服务器则在那个端口监听客户端发送过来的请求。一旦收到请求，服务器（向客户端）发回一个状态行，比如"HTTP/1.1 200 OK"，和（响应的）消息，消息的消息体可能是请求的文件、错误消息、或者其它一些信息。

HTTP使用TCP而不是UDP的原因在于（打开一个）一个网页必须传送很多数据，而TCP协议提供传输控制，按顺序组织数据，和错误纠正。通过HTTP或者HTTPS协议请求的资源由统一资源标识符（Uniform Resource Identifiers，或者，更准确一些，URI）来标识。

客户端与服务器端的结构与交互过程可以表示为下面2张图：

图1、Web客户端-服务器端结构（其中web服务器的超文本链接，即通过网站上的一个链接跳转到了其他服务器上）

图2、Web客户端与服务器端的交互

1.2、HTTP消息

客户端与服务器之间的交互用到了两种类型的消息：请求（Request）和响应（Response）。

HTTP请求的格式为：

  图3、HTTP请求的格式

HTTP响应的格式为：

图4、HTTP响应的格式

从上面可以看出HTTP的请求和响应消息的首部均包含可变数量的字段，用一个空行（blank line）将所有首部字段（header）与消息主体（body）分隔开来。一个首部字段由字段名和随后的冒号、一个空格和字段值组成，字段名不区分大小写。

报文头可分为三类：一类应用于请求，一类应用于响应，还有一类描述主体。有一些报文头（例如：Date）既可用于请求又可用于响应。描述主体的报文头可以出现在POST请求和所有响应报文中。HTTP的首部字段如下图所示：

图5、HTTP首部字段

1.3、HTTP请求的方法

HTTP/1.1协议中共定义了八种方法（有时也叫“动作”）来表明Request-URI指定的资源的不同操作方式：

• OPTIONS 
  返回服务器针对特定资源所支持的HTTP请求方法。也可以利用向Web服务器发送'*'的请求来测试服务器的功能性。
• HEAD 
  向服务器索要与GET请求相一致的响应，只不过响应体将不会被返回。这一方法可以在不必传输整个响应内容的情况下，就可以获取包含在响应消息头中的元信息。
• GET 
  向特定的资源发出请求。注意：GET方法不应当被用于产生“副作用”的操作中，例如在Web Application中。其中一个原因是GET可能会被网络蜘蛛等随意访问。
• POST 
  向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改。
• PUT 
  向指定资源位置上传其最新内容。
• DELETE 
  请求服务器删除Request-URI所标识的资源。
• TRACE 
  回显服务器收到的请求，主要用于测试或诊断。
• CONNECT 
  HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。

方法名称是区分大小写的。当某个请求所针对的资源不支持对应的请求方法的时候，服务器应当返回状态码405（Method Not Allowed）；当服务器不认识或者不支持对应的请求方法的时候，应当返回状态码501（Not Implemented）。

HTTP服务器至少应该实现GET和HEAD方法，其他方法都是可选的。此外，除了上述方法，特定的HTTP服务器还能够扩展自定义的方法。

安全方法

开发者应当意识到他们的软件代表了用户在因特网上进行交互，并且应当告知用户，他们正在进行的操作可能对他们自身或者其他人有未曾预料的重要影响。

特别地，对于GET和HEAD方法而言，除了进行获取资源信息外，这些请求不应当再有任何其他意义。也就是说，这些方法应当被认为是“安全的”，即所谓安全的意味着该操作用于获取信息而非修改信息。客户端应当使用其他“非安全”方法，例如POST、PUT及DELETE来以特殊的方式（通常是按钮而不是超链接）使得客户能够意识到可能要负的责任（例如一个按钮带来的资金交易）或者被告知正在请求的操作可能是不安全的（例如某个文件将被上传或删除）。

但是，不能想当然地认为服务器不会在处理某个GET请求时不会产生任何副作用。事实上，很多动态资源会把这作为其特性。这里重要的区别在于用户并没有请求这一副作用，因此不应由用户为这些副作用承担责任。

幂等方法

假如在不考虑诸如错误或者过期等问题的情况下，若干次请求的副作用与单次请求相同或者根本没有副作用，那么这些请求方法就能够被视作“幂等”的。GET，HEAD，PUT和DELETE方法都有这样的幂等属性，同样由于根据协议，OPTIONS，TRACE都不应有副作用，因此也理所当然也是幂等的。

假如某个由若干个请求做成的请求串行产生的结果在重复执行这个请求串行或者其中任何一个或多个请求后仍没有发生变化，则这个请求串行便是“幂等” 的。但是，可能出现若干个请求做成的请求串行是“非幂等”的，即使这个请求串行中所有执行的请求方法都是幂等的。例如，这个请求串行的结果依赖于某个会在下次执行这个串行的过程中被修改的变量。

1.4、HTTP响应的代码

 服务器程序响应的第一行叫状态行。状态行以HTTP版本号开始，后面跟着3位数字表示响应代码，最后是易读的响应短语。根据第一位可以把响应分成5类：

图6、HTTP响应代码

2、抓包分析

现在我们对HTTP基本上算是了解了，下面我用wireshark抓取打开博客园首页时，我的电脑与博客园服务器的交互过程的HTTP数据包。做好准备工作，关闭一些可能干扰我们抓取打开博客园的相关程序。如下图，我们在浏览器中输入www.cnblogs.com并确定时，首先抓到如下包：

  图7、打开博客园抓取的包

从图中可以看出，我们在浏览器中输入www.cnblogs.com并确定时是向服务器发送了一个HTTP请求消息：GET  /  HTTP/1.1。根据1.2中介绍的HTTP消息的格式，我们知道GET对应request、/对应request-line、HTTP/1.1对应版本号。除了请求行之外，发送了一些首部字段，如：Accept、Accept-Language、User-Agent、Accept-Encoding、Host、Connection等。而且可以看出他们的格式就是：首部字段名: 字段值，注意冒号后面有个空格。

接下来我们看一下GET  /  HTTP/1.1请求的响应消息是怎样的：

图8、GET  /  HTTP/1.1请求的响应消息

响应消息的状态行是：HTTP/1.1  200  OK，其中HTTP/1.1对应版本号、200对应response-code、OK对应response-phrase。除了状态行，还返回了一些首部字段，如：Cache-Control、Content-Type、Content-Encoding、Expires、Last-Modified、Vary、Server等等。（通过上图我们可以看出，博客用的是IIS7.0）

上面抓的是GET的数据包，现在我来看一个POST的数据包——打开博客园首页过程中获取左边的分类信息就是通过POST请求返回的。

图9、POST数据包

我们可以看到，POST /ws/PublicUserService.asmx/GetLoginInfo HTTP/1.1。除了把GET换成了POST之外，其它信息差不多。下面我们放大看下发送的首部字段：

图10、POST /ws/PublicUserService.asmx/GetLoginInfo HTTP/1.1的首部字段

NOTE：本节涉及的一些首部字段我就不在这里解释了。我想，到了这里大家对HTTP的认识应该更深入了一步。

3、POST与GET的差异

1.3中介绍了8种方法，其中GET与POST最基本和常用了。表单提交中get和post方式的区别归纳如下几点：

• GET是从服务器上获取数据，POST是向服务器传送数据。
• GET是把参数数据队列加到提交表单的ACTION属性所指的URL中，值和表单内各个字段一一对应，在URL中可以看到。POST是通过HTTP POST机制，将表单内各个字段与其内容放置在HTML HEADER内一起传送到ACTION属性所指的URL地址。用户看不到这个过程。
• 对于GET方式，服务器端用Request.QueryString获取变量的值，对于POST方式，服务器端用Request.Form获取提交的数据。
• GET传送的数据量较小，不能大于2KB（这主要是因为受URL长度限制）。POST传送的数据量较大，一般被默认为不受限制。但理论上，限制取决于服务器的处理能力。
• GET安全性较低，POST安全性较高。因为GET在传输过程，数据被放在请求的URL中，而如今现有的很多服务器、代理服务器或者用户代理都会将请求URL记录到日志文件中，然后放在某个地方，这样就可能会有一些隐私的信息被第三方看到。另外，用户也可以在浏览器上直接看到提交的数据，一些系统内部消息将会一同显示在用户面前。POST的所有操作对用户来说都是不可见的。

在FORM提交的时候，如果不指定Method，则默认为GET请求（.net默认是POST），Form中提交的数据将会附加在url之后，以?分开与url分开。字母数字字符原样发送，但空格转换为“+”号，其它符号转换为%XX,其中XX为该符号以16进制表示的ASCII（或ISO Latin-1）值。GET请求请提交的数据放置在HTTP请求协议头中，而POST提交的数据则放在实体数据中；GET方式提交的数据最多只能有2048字节，而POST则没有此限制。POST传递的参数在doc里，也就http协议所传递的文本，接受时再解析参数部分。获得参数。一般用POST比较好。POST提交数据是隐式的，GET是通过在url里面传递的，用来传递一些不需要保密的数据，GET是通过在URL里传递参数，POST不是。

说明：关于“POST与GET的差异”查考了网上前辈的资料，由于找不出源头，到处都是转帖，这里就不贴出相关网址了，baidu或Google下就知道了。

4、以一个实例说明C#中如何使用POST、GET等操作

在介绍实例之前，我们要先介绍一下HttpWebRequest和HttpWebResponse，在C#中就是用这两个类实现客户端向服务器端发送HTTP消息、客户端接受服务器端的HTTP响应。

4.1、HttpWebRequest

在设计实现实例之前我们首先要介绍一下HttpWebRequest这个类——提供WebRequest 类的HTTP 特定的实现，HttpWebRequest类对WebRequest中定义的属性和方法提供支持，也对使用户能够直接与使用 HTTP 的服务器交互的附加属性和方法提供支持。

不要使用 HttpWebRequest 构造函数。使用 System.Net.WebRequest.Create 方法初始化新的  HttpWebRequest对象。如果统一资源标识符 (URI) 的方案是  http:// 或  https://，则  Create返回  HttpWebRequest对象。

HTTP消息的首部字段（headers），在HttpWebRequest中表示为公开的属性。下表列出了由属性或方法设置或由系统设置的 HTTP 标头。

如果本地计算机配置指定使用代理，或者如果请求指定代理，则使用代理发送请求。如果未指定代理，则请求发送到服务器。

HttpWebRequest类主要包括如下方法，用于与HTTP服务器交互：

• Abort： 取消对 Internet 资源的请求。
• AddRange： 向请求添加范围标头。
• BeginGetRequestStream：开始对用来写入数据的 Stream 对象的异步请求。
• BeginGetResponse：开始对Internet 资源的异步请求。
• Create：初始化新的 WebRequest。（从WebRequest 继承。）
• CreateDefault：为指定的 URI 方案初始化新的 WebRequest 实例。（从WebRequest 继承。）
• CreateObjRef：创建一个对象，该对象包含生成用于与远程对象进行通信的代理所需的全部相关信息。 （从MarshalByRefObject 继承。）
• EndGetRequestStream：结束对用于写入数据的 Stream 对象的异步请求。
• EndGetResponse：结束对 Internet 资源的异步请求。
• GetRequestStream：获取用于写入请求数据的 Stream 对象。
• GetResponse：返回来自 Internet 资源的响应。
• GetSystemWebProxy：返回当前模拟用户的 Internet Explorer 设置中配置的代理。（从 WebRequest 继承。）
• InitializeLifetimeService：获取控制此实例的生存期策略的生存期服务对象。 （从 MarshalByRefObject 继承。）
• RegisterPrefix：为指定的URI 注册WebRequest 子代。（从WebRequest 继承。）

4.2、HttpWebResponse

在设计实现实例之前我们还要介绍一下HttpWebRequest这个类——提供WebResponse 类的HTTP 特定的实现。此类包含对WebResponse类中的属性和方法的 HTTP 特定用法的支持。HttpWebResponse类用于生成发送HTTP请求和接收HTTP响应的HTTP独立客户端应用程序。

注意

不要混淆 HttpWebResponse 和 HttpResponse 类；后者用于 ASP.NET 应用程序，而且它的方法和属性是通过 ASP.NET 的内部 Response 对象公开的。

决不要直接创建HttpWebResponse类的实例。而应当使用通过调用 HttpWebRequest.GetResponse 所返回的实例。您必须调用 Stream.Close 方法或 HttpWebResponse.Close 方法来关闭响应并将连接释放出来供重用。不必同时调用 Stream.Close 和 HttpWebResponse.Close，但这样做不会导致错误。

从 Internet 资源返回的公共标头信息公开为该类的属性。有关完整的列表，请参见下表。可以从 Headers 属性以名称/值对的形式读取其他标头。下表显示可以通过HttpWebResponse类的属性使用的公共 HTTP 标头。

通过调用GetResponseStream方法，以Stream的形式返回来自 Internet 资源的响应的内容。

HttpWebRequest类主要包括如下方法与HTTP服务器交互：（与HttpWebRequest类相比，方法较少）

• CreateObjRef：创建一个对象，该对象包含生成用于与远程对象进行通信的代理所需的全部相关信息。（从MarshalByRefObject 继承。）
• GetLifetimeService：检索控制此实例的生存期策略的当前生存期服务对象。（从MarshalByRefObject 继承。）
• GetResponseHeader：获取与响应一起返回的标头的内容。
• GetResponseStream：获取流，该流用于读取来自服务器的响应的体。
• InitializeLifetimeService：获取控制此实例的生存期策略的生存期服务对象。（从 MarshalByRefObject 继承。）

4.3、编写WinForm程序打开博客园首页（附源码）

通过前面两小节的介绍，我们对HttpWebRequest类和HttpWebRequest类有所了解，现在我们就应用它们来编写一个小程序来实践。程序界面大概如下：

功能也比较简单，就是通过点击“在WebBrowser中显示”按钮就在下方的 WebBrowser控件中显示博客园首页，通过点击查看“html源码”按钮就弹出一个对话框显示博客园首页的html源码。

首先我们介绍如何实现——通过点击查看“html源码”按钮就弹出一个对话框显示博客园首页的html源码。核心代码如下：

通过点击查看“html源码”按钮就弹出一个对话框显示博客园首页的html源码

其实这个过程更我们通过在浏览器中输入博客园网站打开效果是一样的，只不过在这里我们是通过HttpWebRequest类和HttpWebRequest类的对象来实现的。

然而，通过点击“在WebBrowser中显示”按钮就在下方的 WebBrowser控件中显示博客园首页的功能类似，只不过是在WebBrowser控件中显示且我这里把一些常用的HTTP相关的操作封装到一个命名空间Helper中，便于以后使用，本质跟上面的是一样的。点击下载整个项目的源码。

我这个源码还是比较简陋，只是简单地实现了使用HttpWebRequest类和HttpWebRequest类与HTTP服务器交互，更完善的功能期待你去完成。

 

补充说明：关于url的长度限制问题，IE的url最长可以传 2083 字符（半角），而GET最多只能到2048字符。但是RFC 2616，Hypertext Transfer Protocol -- HTTP/1.1，并没有对url的最大长度做限制。 

 

参考：写此文章时，我参阅了不少文章，我列举其中印象比较深的

• 维基百科（HTTP），http://zh.wikipedia.org/zh-cn/HTTP
• MSDN（HttpWebRequest），http://msdn.microsoft.com/zh-cn/library/8y7x3zz2%28v=VS.80%29.aspx
• MSDN（HttpWebResponse），http://msdn.microsoft.com/zh-cn/library/system.net.httpwebresponse%28VS.80%29.aspx
• TCP/IP协议详解卷3

Todd.log - a place to keep my thoughts on programming

理解HTTP幂等性

基于HTTP协议的Web API是时下最为流行的一种分布式服务提供方式。无论是在大型互联网应用还是企业级架构中，我们都见到了越来越多的SOA或RESTful的Web API。为什么Web API如此流行呢？我认为很大程度上应归功于简单有效的HTTP协议。HTTP协议是一种分布式的面向资源的网络应用层协议，无论是服务器端提供Web服务，还是客户端消费Web服务都非常简单。再加上浏览器、Javascript、AJAX、JSON以及HTML5等技术和工具的发展，互联网应用架构设计表现出了从传统的PHP、JSP、ASP.NET等服务器端动态网页向Web API + RIA（富互联网应用）过渡的趋势。Web API专注于提供业务服务，RIA专注于用户界面和交互设计，从此两个领域的分工更加明晰。在这种趋势下，Web API设计将成为服务器端程序员的必修课。然而，正如简单的Java语言并不意味着高质量的Java程序，简单的HTTP协议也不意味着高质量的Web API。要想设计出高质量的Web API，还需要深入理解分布式系统及HTTP协议的特性。

幂等性定义

本文所要探讨的正是HTTP协议涉及到的一种重要性质：幂等性(Idempotence)。在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 the same as for a single request.

从定义上看，HTTP方法的幂等性是指一次和多次请求某一个资源应该具有同样的副作用。幂等性属于语义范畴，正如编译器只能帮助检查语法错误一样，HTTP规范也没有办法通过消息格式等语法手段来定义它，这可能是它不太受到重视的原因之一。但实际上，幂等性是分布式系统设计中十分重要的概念，而HTTP的分布式本质也决定了它在HTTP中具有重要地位。

分布式事务 vs 幂等设计

为什么需要幂等性呢？我们先从一个例子说起，假设有一个从账户取钱的远程API（可以是HTTP的，也可以不是），我们暂时用类函数的方式记为：

bool withdraw(account_id, amount)

withdraw的语义是从account_id对应的账户中扣除amount数额的钱；如果扣除成功则返回true，账户余额减少amount；如果扣除失败则返回false，账户余额不变。值得注意的是：和本地环境相比，我们不能轻易假设分布式环境的可靠性。一种典型的情况是withdraw请求已经被服务器端正确处理，但服务器端的返回结果由于网络等原因被掉丢了，导致客户端无法得知处理结果。如果是在网页上，一些不恰当的设计可能会使用户认为上一次操作失败了，然后刷新页面，这就导致了withdraw被调用两次，账户也被多扣了一次钱。如图1所示：

图1

这个问题的解决方案一是采用分布式事务，通过引入支持分布式事务的中间件来保证withdraw功能的事务性。分布式事务的优点是对于调用者很简单，复杂性都交给了中间件来管理。缺点则是一方面架构太重量级，容易被绑在特定的中间件上，不利于异构系统的集成；另一方面分布式事务虽然能保证事务的ACID性质，而但却无法提供性能和可用性的保证。

另一种更轻量级的解决方案是幂等设计。我们可以通过一些技巧把withdraw变成幂等的，比如：

int create_ticket() 
bool idempotent_withdraw(ticket_id, account_id, amount)

create_ticket的语义是获取一个服务器端生成的唯一的处理号ticket_id，它将用于标识后续的操作。idempotent_withdraw和withdraw的区别在于关联了一个ticket_id，一个ticket_id表示的操作至多只会被处理一次，每次调用都将返回第一次调用时的处理结果。这样，idempotent_withdraw就符合幂等性了，客户端就可以放心地多次调用。

基于幂等性的解决方案中一个完整的取钱流程被分解成了两个步骤：1.调用create_ticket()获取ticket_id；2.调用idempotent_withdraw(ticket_id, account_id, amount)。虽然create_ticket不是幂等的，但在这种设计下，它对系统状态的影响可以忽略，加上idempotent_withdraw是幂等的，所以任何一步由于网络等原因失败或超时，客户端都可以重试，直到获得结果。如图2所示：

图2

和分布式事务相比，幂等设计的优势在于它的轻量级，容易适应异构环境，以及性能和可用性方面。在某些性能要求比较高的应用，幂等设计往往是唯一的选择。

HTTP的幂等性

HTTP协议本身是一种面向资源的应用层协议，但对HTTP协议的使用实际上存在着两种不同的方式：一种是RESTful的，它把HTTP当成应用层协议，比较忠实地遵守了HTTP协议的各种规定；另一种是SOA的，它并没有完全把HTTP当成应用层协议，而是把HTTP协议作为了传输层协议，然后在HTTP之上建立了自己的应用层协议。本文所讨论的HTTP幂等性主要针对RESTful风格的，不过正如上一节所看到的那样，幂等性并不属于特定的协议，它是分布式系统的一种特性；所以，不论是SOA还是RESTful的Web API设计都应该考虑幂等性。下面将介绍HTTP GET、DELETE、PUT、POST四种主要方法的语义和幂等性。

HTTP GET方法用于获取资源，不应有副作用，所以是幂等的。比如：GET http://www.bank.com/account/123456，不会改变资源的状态，不论调用一次还是N次都没有副作用。请注意，这里强调的是一次和N次具有相同的副作用，而不是每次GET的结果相同。GET http://www.news.com/latest-news这个HTTP请求可能会每次得到不同的结果，但它本身并没有产生任何副作用，因而是满足幂等性的。

HTTP DELETE方法用于删除资源，有副作用，但它应该满足幂等性。比如：DELETE http://www.forum.com/article/4231，调用一次和N次对系统产生的副作用是相同的，即删掉id为4231的帖子；因此，调用者可以多次调用或刷新页面而不必担心引起错误。

比较容易混淆的是HTTP POST和PUT。POST和PUT的区别容易被简单地误认为“POST表示创建资源，PUT表示更新资源”；而实际上，二者均可用于创建资源，更为本质的差别是在幂等性方面。在HTTP规范中对POST和PUT是这样定义的：

The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line ...... If a resource has been created on the origin server, the response SHOULD be 201 (Created) and contain an entity which describes the status of the request and refers to the new resource, and a Location header.

The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI.

POST所对应的URI并非创建的资源本身，而是资源的接收者。比如：POST http://www.forum.com/articles的语义是在http://www.forum.com/articles下创建一篇帖子，HTTP响应中应包含帖子的创建状态以及帖子的URI。两次相同的POST请求会在服务器端创建两份资源，它们具有不同的URI；所以，POST方法不具备幂等性。而PUT所对应的URI是要创建或更新的资源本身。比如：PUT http://www.forum/articles/4231的语义是创建或更新ID为4231的帖子。对同一URI进行多次PUT的副作用和一次PUT是相同的；因此，PUT方法具有幂等性。

在介绍了几种操作的语义和幂等性之后，我们来看看如何通过Web API的形式实现前面所提到的取款功能。很简单，用POST /tickets来实现create_ticket；用PUT /accounts/account_id/ticket_id&amount=xxx来实现idempotent_withdraw。值得注意的是严格来讲amount参数不应该作为URI的一部分，真正的URI应该是/accounts/account_id/ticket_id，而amount应该放在请求的body中。这种模式可以应用于很多场合，比如：论坛网站中防止意外的重复发帖。

总结

上面简单介绍了幂等性的概念，用幂等设计取代分布式事务的方法，以及HTTP主要方法的语义和幂等性特征。其实，如果要追根溯源，幂等性是数学中的一个概念，表达的是N次变换与1次变换的结果相同，有兴趣的读者可以从Wikipedia上进一步了解。

参考

RFC 2616, Hypertext Transfer Protocol -- HTTP/1.1, Method Definitions
The Importance of Idempotence
Stackoverflow - PUT vs POST in REST