总结

使用PUT创建或用请求中包含的表示定义的状态替换目标资源的状态。这种标准化的预期效果是幂等的，因此它通知中介，在通信失败的情况下，他们可以重复请求。 否则使用POST(包括创建或替换目标资源以外的资源状态)。其预期效果不规范，中介机构不能依赖任何普遍属性。

参考文献

关于POST和PUT请求方法之间语义差异的最新权威描述在RFC 7231中给出(Roy Fielding, Julian Reschke, 2014):

The fundamental difference between the POST and PUT methods is highlighted by the different intent for the enclosed representation. The target resource in a POST request is intended to handle the enclosed representation according to the resource's own semantics, whereas the enclosed representation in a PUT request is defined as replacing the state of the target resource. Hence, the intent of PUT is idempotent and visible to intermediaries, even though the exact effect is only known by the origin server.

换句话说，PUT的预期效果是标准化的(用请求中所包含的表示定义的状态创建或替换目标资源的状态)，因此对所有目标资源都是通用的，而POST的预期效果不是标准化的，因此是特定于每个目标资源的。因此POST可以用于任何事情，包括实现PUT和其他请求方法(GET、HEAD、DELETE、CONNECT、OPTIONS和TRACE)的预期效果。

But it is recommended to always use the more specialized request method rather than POST when applicable because it provides more information to intermediaries for automating information retrieval (since GET, HEAD, OPTIONS, and TRACE are defined as safe), handling communication failure (since GET, HEAD, PUT, DELETE, OPTIONS, and TRACE are defined as idempotent), and optimizing cache performance (since GET and HEAD are defined as cacheable), as explained in It Is Okay to Use POST (Roy Fielding, 2009):

POST only becomes an issue when it is used in a situation for which some other method is ideally suited: e.g., retrieval of information that should be a representation of some resource (GET), complete replacement of a representation (PUT), or any of the other standardized methods that tell intermediaries something more valuable than “this may change something.” The other methods are more valuable to intermediaries because they say something about how failures can be automatically handled and how intermediate caches can optimize their behavior. POST does not have those characteristics, but that doesn’t mean we can live without it. POST serves many useful purposes in HTTP, including the general purpose of “this action isn’t worth standardizing.”

PUT是一种将内容“上载”到特定URI或覆盖该URI中已有内容的方法。

另一方面，POST是提交与给定URI相关的数据的一种方式。

参考HTTP RFC

什么时候使用一种或另一种应该是相当简单的，但复杂的措辞对我们许多人来说是困惑的来源。

何时使用:

当您希望修改已经是资源集合一部分的单个资源时，请使用PUT。PUT将整个资源替换。示例:PUT /resources/:resourceId 旁注:如果您想更新资源的一部分，请使用PATCH。

当您希望在资源集合下添加子资源时，请使用POST。 示例:POST => /resources

一般来说:

通常，在实践中，总是使用PUT进行UPDATE操作。 CREATE操作总是使用POST。

例子:

GET /company/reports =>获取所有报告 GET /company/reports/{id} =>获取以"id"标识的报告信息 POST /company/reports => PUT /company/reports/{id} =>更新“id”标识的报告信息 PATCH /company/reports/{id} =>更新“id”标识的部分报告信息 DELETE /company/reports/{id} =>删除报表

值得一提的是，POST容易受到一些常见的跨站请求伪造(CSRF)攻击，而PUT则不会。

当受害者访问attackersite.com时，下面的CSRF是不可能的。

攻击的效果是，受害者无意中删除一个用户，只是因为它(受害者)在访问attackersite.com之前以admin身份登录target.site.com:

attackersite.com上的恶意代码:

案例1:正常请求。保存的target.site.com cookie将自动由浏览器发送:(注意:只支持PUT，在端点，是更安全的，因为它是不支持<form>属性值)

<!--deletes user with id 5-->
<form id="myform" method="post" action="http://target.site.com/deleteUser" >
    <input type="hidden" name="userId" value="5">
</form>
<script>document.createElement('form').submit.call(document.getElementById('myform'));</script>

案例2:XHR请求。保存的target.site.com cookie将被浏览器自动发送:(注意:只支持PUT，在端点，是更安全的，因为尝试发送PUT将触发一个preflight请求，其响应将阻止浏览器请求deleteUser页面)

//deletes user with id 5
var xhr = new XMLHttpRequest();
xhr.open("POST", "http://target.site.com/deleteUser");
xhr.withCredentials=true;
xhr.send(["userId=5"]);

MDN Ref: [..]与“简单请求”(上面讨论过)不同，——[[意思是:POST/GET/HEAD]]——，对于“预飞行”请求，浏览器首先使用OPTIONS方法发送一个HTTP请求[..]

Cors在行动:[..]某些类型的请求，如DELETE或PUT，在发出实际请求之前需要进一步请求服务器的许可。]所谓的飞行前请求[..]

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。