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

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

参考HTTP RFC

PUT和POST都是休息方法。

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

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

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

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

简单来说，你可以说:

1.HTTP Get:用于获取一个或多个条目

2.HTTP Post:用于创建条目

3.HTTP Put:用于更新条目

4.HTTP补丁:用于部分更新项目

5.HTTP删除:用于删除项目

GET: Retrieves data from the server. Should have no other effect. PUT: Replaces target resource with the request payload. Can be used to update or create a new resource. PATCH: Similar to PUT, but used to update only certain fields within an existing resource. POST: Performs resource-specific processing on the payload. Can be used for different actions including creating a new resource, uploading a file, or submitting a web form. DELETE: Removes data from the server. TRACE: Provides a way to test what the server receives. It simply returns what was sent. OPTIONS: Allows a client to get information about the request methods supported by a service. The relevant response header is Allow with supported methods. Also used in CORS as preflight request to inform the server about actual the request method and ask about custom headers. HEAD: Returns only the response headers. CONNECT: Used by the browser when it knows it talks to a proxy and the final URI begins with https://. The intent of CONNECT is to allow end-to-end encrypted TLS sessions, so the data is unreadable to a proxy.

总结

使用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.”