根据HTTP方法定义操作

HTTP协议定义了许多为请求分配语义的方法。大多数RESTful web api使用的常见HTTP方法有:

GET在指定URI处检索资源的表示形式。响应消息的主体包含所请求资源的详细信息。

POST在指定的URI上创建一个新资源。请求消息的主体提供了新资源的详细信息。注意，POST还可以用于触发不实际创建资源的操作。

PUT在指定的URI上创建或替换资源。请求消息的主体指定要创建或更新的资源。

PATCH执行资源的部分更新。请求体指定要应用于资源的更改集。

DELETE删除指定URI上的资源。

特定请求的效果应取决于资源是集合还是单个项。下表通过电子商务示例总结了大多数RESTful实现采用的常见约定。并不是所有这些请求都可以实现——这取决于具体的场景。

POST、PUT和PATCH之间的区别可能令人困惑。

POST请求创建一个资源。服务器为新资源分配URI，并将该URI返回给客户端。在REST模型中，您经常对集合应用POST请求。新资源被添加到集合中。POST请求还可以用于将数据提交到现有资源进行处理，而不需要创建任何新资源。

A PUT request creates a resource or updates an existing resource. The client specifies the URI for the resource. The request body contains a complete representation of the resource. If a resource with this URI already exists, it is replaced. Otherwise, a new resource is created, if the server supports doing so. PUT requests are most frequently applied to resources that are individual items, such as a specific customer, rather than collections. A server might support updates but not creation via PUT. Whether to support creation via PUT depends on whether the client can meaningfully assign a URI to a resource before it exists. If not, then use POST to create resources and PUT or PATCH to update.

PATCH请求对现有资源执行部分更新。客户端为资源指定URI。请求体指定要应用于资源的一组更改。这可能比使用PUT更有效，因为客户端只发送更改，而不是资源的整个表示。从技术上讲，如果服务器支持的话，PATCH还可以创建一个新资源(通过指定一组对“null”资源的更新)。

PUT请求必须是等幂的。如果客户端多次提交相同的PUT请求，结果应该总是相同的(相同的资源将被修改为相同的值)。POST和PATCH请求不能保证是等幂的。

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来创建或修改资源。

根据HTTP方法定义操作

HTTP协议定义了许多为请求分配语义的方法。大多数RESTful web api使用的常见HTTP方法有:

GET在指定URI处检索资源的表示形式。响应消息的主体包含所请求资源的详细信息。

POST在指定的URI上创建一个新资源。请求消息的主体提供了新资源的详细信息。注意，POST还可以用于触发不实际创建资源的操作。

PUT在指定的URI上创建或替换资源。请求消息的主体指定要创建或更新的资源。

PATCH执行资源的部分更新。请求体指定要应用于资源的更改集。

DELETE删除指定URI上的资源。

特定请求的效果应取决于资源是集合还是单个项。下表通过电子商务示例总结了大多数RESTful实现采用的常见约定。并不是所有这些请求都可以实现——这取决于具体的场景。

POST、PUT和PATCH之间的区别可能令人困惑。

POST请求创建一个资源。服务器为新资源分配URI，并将该URI返回给客户端。在REST模型中，您经常对集合应用POST请求。新资源被添加到集合中。POST请求还可以用于将数据提交到现有资源进行处理，而不需要创建任何新资源。

A PUT request creates a resource or updates an existing resource. The client specifies the URI for the resource. The request body contains a complete representation of the resource. If a resource with this URI already exists, it is replaced. Otherwise, a new resource is created, if the server supports doing so. PUT requests are most frequently applied to resources that are individual items, such as a specific customer, rather than collections. A server might support updates but not creation via PUT. Whether to support creation via PUT depends on whether the client can meaningfully assign a URI to a resource before it exists. If not, then use POST to create resources and PUT or PATCH to update.

PATCH请求对现有资源执行部分更新。客户端为资源指定URI。请求体指定要应用于资源的一组更改。这可能比使用PUT更有效，因为客户端只发送更改，而不是资源的整个表示。从技术上讲，如果服务器支持的话，PATCH还可以创建一个新资源(通过指定一组对“null”资源的更新)。

PUT请求必须是等幂的。如果客户端多次提交相同的PUT请求，结果应该总是相同的(相同的资源将被修改为相同的值)。POST和PATCH请求不能保证是等幂的。

POST和PUT之间的区别在于PUT是幂等的，这意味着多次调用相同的PUT请求总是会产生相同的结果(没有副作用)，而另一方面，重复调用POST请求可能会产生多次创建相同资源的(额外的)副作用。

GET:使用GET的请求只检索数据，也就是说它请求指定资源的表示

POST:向服务器发送数据以创建资源。请求体的类型由Content-Type报头表示。它通常会导致服务器的状态变化或副作用

PUT:创建一个新资源或用请求有效负载替换目标资源的表示

PATCH:用于对资源应用部分修改

DELETE:删除指定资源

TRACE:它沿着通往目标资源的路径执行消息循环测试，提供了一种有用的调试机制

OPTIONS:用于描述目标资源的通信选项，客户端可以为OPTIONS方法指定一个URL，或者一个星号(*)来引用整个服务器。

HEAD:它请求与GET请求相同的响应，但没有响应体

CONNECT:它建立到目标资源标识的服务器的隧道，可用于访问使用SSL (HTTPS)的网站

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

何时使用:

当您希望修改已经是资源集合一部分的单个资源时，请使用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，在发出实际请求之前需要进一步请求服务器的许可。]所谓的飞行前请求[..]