总结

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

REST-ful用法

POST用于创建一个新资源，然后返回资源URI

EX 
      REQUEST : POST ..../books
        {
        "book":"booName",
        "author":"authorName"
        }

这个调用可以创建一本新书，并返回该书籍的URI

Response ...THE-NEW-RESOURCE-URI/books/5

PUT是用来替换资源的，如果资源存在，就更新它，如果资源不存在，就创建它，

REQUEST : PUT ..../books/5
{
"book":"booName",
"author":"authorName"
}

使用PUT，我们知道资源标识符，但POST将返回新的资源标识符

无剩余用途

POST用于在服务器端发起一个操作，这个操作可能会创建资源，也可能不会创建资源，但是这个操作会有副作用，它总是会改变服务器上的一些东西

PUT用于放置或替换特定URL上的文字内容

REST-ful和non - rest风格的另一个区别

POST是非幂等操作:如果对同一个请求执行多次，将导致一些变化。

PUT是幂等操作:如果对同一个请求执行多次，它将没有副作用。

只有语义。

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

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

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

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

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

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

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

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

DELETE:删除指定资源

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

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

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

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

POST被认为是某种工厂类型的方法。您将数据包含在其中以创建您想要的内容，而另一端的任何内容都知道如何使用它。PUT用于更新给定URL上的现有数据，或者当您知道URI将是什么并且它还不存在时创建一些新的东西(与POST相反，POST将创建一些东西并在必要时返回URL)。