HTTP协议中PUT和POST使用区别

HTTP类型

http协议类型有8种，分别是： 
OPTIONS：返回服务器针对特定资源所支持的HTTP请求方法。也可以利用向Web服务器发送’*’的请求来测试服务器的功能性。 
HEAD：向服务器索要与GET请求相一致的响应，只不过响应体将不会被返回。这一方法可以在不必传输整个响应内容的情况下，就可以获取包含在响应消息头中的元信息。 
GET：向特定的资源发出请求。 
POST：向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的创建和/或已有资源的修改。 
PUT：向指定资源位置上传其最新内容。 
DELETE：请求服务器删除Request-URI所标识的资源。 
TRACE：回显服务器收到的请求，主要用于测试或诊断。 
CONNECT：HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。 
之前用的get和put比较多，遇到一个post类型，就不知道该怎么用了，所以找了些资料来简单说一下put和post的区别。

创建，更新与HTTP幂等性

构建基于REST API的开发者对于何时使用HTTP PUT与POST有很大的误解与困惑。有些人认为POST 应用于创建资源，而PUT则用于更新资源。其他人则认为PUT用于创建而POST用于更改资源。这两种说法都不太确切。 
通常，开发者将每个HTTP方法与CRUP操作一一对应。 
CRUD HTTP 
Create POST 
Read GET 
Update PUT 
Delete DELETE 
的确是这样，而且GET与DELETE对应的操作是很明确的，但论及与create和update对应的HTTP方法时要取决于幂等性。 
状态统一性

状态统一性

状态统一性在HTTP规范中是一个很重要的概念。它规定对于执行多次相同的HTTP请求，处于服务端的资源的状态是相同的。GET，HEAD， PUT与DELETE都具有这种特性，但POST没有。 
为便于说明状态统一性，我们会使用一个Account集合(“/accounts”)，并且为了简洁我们假设每个account资源都有三个属性：givenName, surname，和status。 
假设你使用HTTP PUT方法提交了一个update请求。在请求体中，你设置了givenName和surname的值分别为”John”和”Smith”。接着你又提交了另一个HTTP PUT的请求，这次你将givenName的值设置为”Johnny”。它是幂等的么？不。为什么呢？因为在这两次请求的间隙，其他请求可能已经改变了account资源的服务端状态。例如，在这两次请求之间，status的值可能已经变成了“blocked”。我们示范的请求在重复提交时不能保证在服务端的account资源的状态是相同的。

请求

HTTP/1.1 PUT /accounts/abcdef1234
{
      “givenName”: “John”,
      “surname”: “Smith”
}
  
  
  
  

   
   
   
   
1
   
   
   
   
2
   
   
   
   
3
   
   
   
   
4
   
   
   
   
5
  
  
  
  

这两次请求后可能的account状态。 (受其他请求的副作用影响):

{
      “givenName”: “John”,
      “surname”: “Smith”,
      “status”: “enabled”
}
  
  
  
  

   
   
   
   
1
   
   
   
   
2
   
   
   
   
3
   
   
   
   
4
   
   
   
   
5
  
  
  
  

或

{
      “givenName”: “John”,
      “surname”: “Smith”,
      "status”: “disabled”
}
  
  
  
  

   
   
   
   
1
   
   
   
   
2
   
   
   
   
3
   
   
   
   
4
   
   
   
   
5
  
  
  
  

引用Dino Chiesa所述, “PUT 意为提交一个资源——用一个不同的事物完全替代给定的URL下的所有可访问资源。” 要使用PUT请求，你必须发送所有可访问属性/值，而不仅仅是你想要改变的那些。 如果我们在发送givenName和surname时加上状态值“disabled”，则本次调用是幂等的并且消除了副作用。幂等性是HTTP规范的一项基本属性，并且必须确保web的互操作性与规模。 
最后，我们应该指出HTTP状态统一性只能应用于服务端状态——非客户端。例如，某一客户端成功地发送了一个服务端状态统一请求，并立即再次发送这个请求但返回了一个错误（例如可能是由于违反了服务端某种约束），对于 HTTP这仍是‘合法’的。因为这个请求没有对服务端资源状态产生影响，HTTP幂等性没有破坏。

HTTP POST vs HTTP PUT

既然已经清楚了状态统一性，在执行创建和更新操作时你应该使用哪个方法呢？以下是用于合理使用这些方法的快速参考。

创建

在不知道资源标识符时你应该使用POST来创建资源。使用POST创建资源时，返回“201 Created”状态和新建资源的位置是很好的实践，因为新建资源的位置在提交时是未知的。这可以使客户端稍后访问新创建的资源如果需要的话。

HTTP/1.1 POST /accounts
{ … }
  
  
  
  

   
   
   
   
1
   
   
   
   
2
   
   
   
   
3
   
   
   
   
4
  
  
  
  

响应:

201 Created
Location: https://api.stormpath.com/accounts/abcdef1234
  
  
  
  

   
   
   
   
1
   
   
   
   
2
  
  
  
  

当你允许客户端指定新建资源的资源标识符时要使用PUT。但要记住，因为PUT是幂等的，你必须要发送所有可能的值。

HTTP/1.1 PUT /accounts/abcdef1234

{ “givenName”: “John”, “surname”: “Smith”, “status”: “enabled” }
  
  
  
  

   
   
   
   
1
   
   
   
   
2
   
   
   
   
3
   
   
   
   
4
   
   
   
   
5
   
   
   
   
6
   
   
   
   
7
  
  
  
  

更新

你可以使用POST更新全部或一部分值。 
HTTP/1.1 POST /accounts/abcdef1234
{
“status”: “disabled”
}
Response 200 OK 
如果你想用PUT更新某一资源，则必须要更新资源的全部属性。你必须要在PUT请求中发送所有属性值以保证幂等性。

HTTP/1.1 PUT /accounts/abcdef1234
{      //FULL RESOURCE UPDATE
      “givenName”: “J”,
      “surname”: “Smith”,
      “status”: “Enabled”
}
  
  
  
  

   
   
   
   
1
   
   
   
   
2
   
   
   
   
3
   
   
   
   
4
   
   
   
   
5
   
   
   
   
6
  
  
  
  

你也可以使用POST发送所有值，这样服务端状态与处理PUT请求的结果是一样的——这不是HTTP规范所必需的。注意幂等性与HTTP缓存服务器的缓存有较强的关联，并且POST请求通常是非缓存的。如果你对缓存的副作用感冒的话，你可以使用POST来执行全部或部分更新。 
POST是目前惟一的状态不统一的方法。HTTP规范对它的定义也很宽泛，并且大体上将它定义为了一个“服务端处理指令”。这就意味着在POST请求中做任何处理都是“安全”的。 
最后我们要注意HTTP规范中还没有完成的另一个称为PATCH的方法。PATCH意为用于执行部分更新时的POST的替代品。然而，因为POST已经可以处理部分更新，HTTP协会似乎没有急着批准和完成PATCH的必要了。但如果批准了，PATCH将会加入POST作为另一个状态不统一的HTTP方法。 
http://www.oschina.net/translate/put-or-post