PUT和POST都是休息方法。

PUT——如果我们使用PUT两次发出相同的请求，两次都使用相同的参数，那么第二次请求将没有任何影响。这就是为什么PUT通常用于Update场景，使用相同的参数多次调用Update不会比初始调用做更多的事情，因此PUT是幂等的。

POST不是幂等的，例如Create将在目标中创建两个独立的条目，因此它不是幂等的，因此Create在POST中被广泛使用。

每次使用具有相同参数的POST进行相同的调用将导致发生两种不同的情况，因此POST通常用于Create场景

请参阅:http://zacharyvoase.com/2009/07/03/http-post-put-diff/

最近，我对web开发人员的一个流行误解感到非常恼火，他们认为POST是用来创建资源的，而PUT是用来更新/更改资源的。

如果你看一下RFC 2616的第55页(“超文本传输协议- HTTP/1.1”)，第9.6节(“PUT”)，你会看到PUT实际上是干什么的:

PUT方法要求将所包含的实体存储在所提供的Request-URI下。

还有一个方便的段落解释了POST和PUT之间的区别:

The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI. The URI in a POST request identifies the resource that will handle the enclosed entity. That resource might be a data-accepting process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request identifies the entity enclosed with the request – the user agent knows what URI is intended and the server MUST NOT attempt to apply the request to some other resource.

它没有提到更新/创建之间的区别，因为这不是它的重点。这是关于这两者之间的区别:

obj.set_attribute(value) # A POST request.

这:

obj.attribute = value # A PUT request.

所以，请停止这种流行的误解的传播。阅读rfc。

PUT和POST都是休息方法。

PUT——如果我们使用PUT两次发出相同的请求，两次都使用相同的参数，那么第二次请求将没有任何影响。这就是为什么PUT通常用于Update场景，使用相同的参数多次调用Update不会比初始调用做更多的事情，因此PUT是幂等的。

POST不是幂等的，例如Create将在目标中创建两个独立的条目，因此它不是幂等的，因此Create在POST中被广泛使用。

每次使用具有相同参数的POST进行相同的调用将导致发生两种不同的情况，因此POST通常用于Create场景

Post和Put主要用于发布数据和其他更新数据。但是你可以只对post request做同样的事情。

HTTP PUT:

PUT将一个文件或资源放在一个特定的URI中，并且正是在这个URI中。如果该URI上已经有文件或资源，PUT将替换该文件或资源。如果没有文件或资源，PUT会创建一个。PUT是幂等的，但矛盾的是PUT响应是不可缓存的。

PUT的HTTP 1.1 RFC位置

HTTP POST:

POST将数据发送到特定的URI，并期望该URI上的资源处理请求。此时，web服务器可以确定在指定资源的上下文中如何处理数据。POST方法不是幂等的，但是POST响应是可缓存的，只要服务器设置了适当的Cache-Control和Expires头。

正式的HTTP RFC指定POST为:

现有资源的注释; 在公告栏、新闻组、邮件列表上发布消息， 或类似的文章组; 提供一个数据块，例如提交的结果 表单，来一个数据处理过程; 通过追加操作扩展数据库。

POST的HTTP 1.1 RFC位置

POST和PUT的区别:

RFC本身解释了核心差异:

The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI. The URI in a POST request identifies the resource that will handle the enclosed entity. That resource might be a data-accepting process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request identifies the entity enclosed with the request -- the user agent knows what URI is intended and the server MUST NOT attempt to apply the request to some other resource. If the server desires that the request be applied to a different URI, it MUST send a 301 (Moved Permanently) response; the user agent MAY then make its own decision regarding whether or not to redirect the request.

此外，更简单地说，RFC 7231章节4.3.4 PUT声明(强调添加)，

4.3.4. 把 PUT方法请求目标资源的状态为 用表示形式定义的状态创建或替换 包含在请求消息有效负载中。

使用正确的方法，抛开无关:

REST ROA相对于SOAP的一个好处是，当使用HTTP REST ROA时，它鼓励正确使用HTTP动词/方法。因此，例如，当您想要在该确切位置创建资源时，才会使用PUT。而且您永远不会使用GET来创建或修改资源。

给出rest风格资源的示例:

带有一堆图书信息的POST /books可能会创建一本新书，并响应标识该图书的新URL: /books/5。

PUT /books/5必须创建一个ID为5的新书，或者用ID 5替换现有的书。

在非资源风格中，POST可以用于几乎任何具有副作用的事情。另一个区别是PUT应该是幂等的:同一个数据的多个PUT到同一个URL应该没问题，而多个POST可能会创建多个对象或POST操作所做的任何事情。