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

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

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

参考HTTP RFC

只有语义。

HTTP PUT应该接受请求体，然后将其存储在由URI标识的资源中。

HTTP POST更为通用。它应该在服务器上发起一个操作。该操作可以是将请求体存储在由URI标识的资源中，也可以是不同的URI，也可以是不同的操作。

PUT类似于文件上传。对URI的put操作恰好影响该URI。对URI的POST可以产生任何效果。

实际上，除了他们的头衔之外，没有什么不同。GET和其他方法之间实际上有一个基本的区别。使用“GET”-Request方法，发送url地址行中的数据，首先用问号分隔，然后用&符号分隔。

但是使用“POST”-request方法，您不能通过url传递数据，而是必须将数据作为请求的所谓“主体”中的对象传递。在服务器端，您必须读取接收到的内容正文，以便获得发送的数据。 但另一方面，当你发送"GET"-Request时，就不可能在body中发送内容。

“GET”只用于获取数据而“POST”用于发布数据的说法是绝对错误的。没有人可以阻止你创建新的内容，删除现有的内容，编辑现有的内容或做任何在后端，基于数据，这是由“GET”请求或由“POST”请求发送。没有人能阻止你在后端编码，用一个"POST"-Request，客户端请求一些数据。

对于请求，无论使用哪种方法，您都调用URL并发送或不发送一些数据来指定，您希望将哪些信息传递给服务器以处理您的请求，然后客户端从服务器获得一个答案。数据可以包含你想要发送的任何东西，后端可以对数据做任何它想做的事情，响应可以包含任何你想要放在那里的信息。

只有这两个基本方法。GET和POST。但使它们不同的是它们的结构，而不是你在后端编写的代码。在后端，您可以使用接收到的数据编写任何您想要的代码。但是使用“POST”请求，你必须在正文中发送/检索数据，而不是在url-addressline中，而使用“GET”请求，你必须在url-addressline中发送/检索数据，而不是在正文中。这是所有。

所有其他的方法，比如"PUT"， "DELETE"等等，它们都有和"POST"相同的结构。

如果你想隐藏一些内容，POST方法主要被使用，因为无论你在url-addressline中写什么，这都将被保存在缓存中，GET-Method与用数据写url-addressline是一样的。因此，如果你想发送敏感数据，不一定总是用户名和密码，但例如一些id或哈希，你不希望显示在url地址行，那么你应该使用POST方法。

此外，URL-Addressline的长度被限制为1024个符号，而“POST”-方法则不受限制。因此，如果数据量较大，则可能无法使用GET-Request发送数据，而需要使用POST-Request。这也是post请求的另一个优点。

但是当您没有复杂的文本要发送时，处理get请求要容易得多。 否则，这是POST方法的另一个优点，使用get方法，您需要对文本进行url编码，以便能够在文本甚至空格中发送一些符号。但是使用POST方法没有任何限制，您的内容不需要以任何方式更改或操作。

PUT和POST都是休息方法。

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

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

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

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

何时使用:

当您希望修改已经是资源集合一部分的单个资源时，请使用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} =>删除报表