他们似乎都在向身体内的服务器发送数据，那么是什么让他们与众不同呢？
HTTP PUT：
PUT将文件或资源放在特定的URI上，并且恰好放在该URI上。如果该URI上已存在文件或资源，则PUT将替换该文件或资源。如果那里没有文件或资源，PUT会创建一个。 PUT是idempotent，但矛盾的是PUT响应不可缓存。
HTTP POST：
POST将数据发送到特定URI，并期望该URI处的资源处理该请求。此时，Web服务器可以确定如何处理指定资源的上下文中的数据。 POST方法不是idempotent，但只要服务器设置适当的Cache-Control和Expires标头，POST响应就是可缓存的。
官方HTTP RFC指定POST为：
HTTP 1.1 RFC location for POST
POST和PUT之间的区别：
RFC本身解释了核心差异：
POST和PUT请求之间的根本区别体现在Request-URI的不同含义上。 POST请求中的URI标识将处理所包含实体的资源。该资源可能是数据接受过程，某些其他协议的网关或接受注释的单独实体。相反，PUT请求中的URI标识请求附带的实体 - 用户代理知道URI的用途，并且服务器不得尝试将请求应用于其他资源。如果服务器希望将请求应用于不同的URI，它必须发送301（永久移动）响应;然后，用户代理可以自己决定是否重定向请求。
使用正确的方法，无关：
REST ROA与SOAP的一个好处是，当使用HTTP REST ROA时，它鼓励正确使用HTTP谓词/方法。因此，例如，当您想要在该确切位置创建资源时，您将仅使用PUT。并且您永远不会使用GET来创建或修改资源。
REST要求开发人员以与协议定义一致的方式显式地使用HTTP方法。这个基本的REST设计原则在创建，读取，更新和删除（CRUD）操作和HTTP方法之间建立了一对一的映射。根据这个映射：
•要在服务器上创建资源，请使用POST。
•要检索资源，请使用GET。
•要更改资源的状态或更新资源，请使用PUT。
•要删除或删除资源，请使用DELETE。
POST和PUT之间的区别在于PUT是幂等的，这意味着多次调用相同的PUT请求将始终产生相同的结果（没有副作用），而另一方面，重复调用POST请求可能有（附加）多次创建相同资源的副作用。
GET：使用GET的请求仅检索数据，即它请求指定资源的表示
POST：它将数据发送到服务器以创建资源。请求正文的类型由Content-Type标头指示。它通常会导致服务器上的状态或副作用发生变化
PUT：创建新资源或用请求有效负载替换目标资源的表示
PATCH：用于对资源进行部分修改
DELETE：删除指定的资源
TRACE：它沿着目标资源的路径执行消息循环测试，提供有用的调试机制
OPTIONS：用于描述目标资源的通信选项，客户端可以指定OPTIONS方法的URL，或者用星号（*）来表示整个服务器。
HEAD：它要求一个与GET请求相同的响应，但是没有响应主体
CONNECT：它建立到目标资源标识的服务器的隧道，可用于访问使用SSL（HTTPS）的网站
值得一提的是，POST受到一些常见的CSRF攻击，而PUT则没有。
当受害者访问attackersite.com时，PUT无法实现以下CSRF：
正常请求（发送cookie）:( PUT不是受支持的属性值）
<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>
XHR请求（发送cookie）:( PUT将触发预检请求）
var xhr = new XMLHttpRequest();
xhr.open("POST", "http://target.site.com/deleteUser");
xhr.withCredentials=true;
xhr.send(["userId=5"]);
只是
POST用于创建资源并返回资源URI EX
REQUEST : POST ..../books
{
"book":"booName",
"author":"authorName"
}
这个调用应该创建一本新书并返回那本书URI
Response ..../books/5
PUT用于替换资源，如果该资源存在则只需更新它，但如果该资源不存在则创建它，
REQUEST : PUT ..../books/5
{
"book":"booName",
"author":"authorName"
}
使用PUT我们将提供资源标识符，但POST将返回新的资源标识符
只有语义。
HTTP PUT应该接受请求的主体，然后将其存储在URI标识的资源中。
HTTP POST更通用。它应该在服务器上启动一个动作。该操作可以是将请求主体存储在由URI标识的资源中，或者它可以是不同的URI，或者它可以是不同的动作。
PUT就像文件上传。对URI的放置会完全影响该URI。对URI的POST可能会产生任何影响。
举例说明REST风格的资源：
带有大量图书信息的“POST / books”可能会创建一本新书，并使用标识该书的新URL进行回复：“/ books / 5”。
“PUT / books / 5”必须创建id为5的新书，或者用ID 5替换现有书籍。
在非资源风格中，POST可用于任何具有副作用的事物。另一个区别是PUT应该是幂等的 - 同一个URL的相同数据的多个PUT应该没问题，多个POST可能会创建多个对象或者你的POST操作。
据我所知，PUT主要用于更新记录。
但是要清楚该PUT通常会“取代”现有记录，如果它在那里并创建，如果它不存在..
其他人已经发布了很好的答案，我只想添加大多数语言，框架和用例，你将会比PUT更频繁地处理POST。到PUT，DELETE等基本上是琐事问题。
POST被认为是工厂类型的方法。您可以在其中包含数据以创建您想要的内容，而另一端则知道如何处理它。 PUT用于更新给定URL的现有数据，或者当您知道URI将会是什么并且它尚不存在时创建新的东西（而不是POST将创建一些东西并返回一个URL到如有必要）。
请参阅：http://zacharyvoase.com/2009/07/03/http-post-put-diff/
最近，网络开发人员普遍误以为使用POST来创建资源，而PUT用于更新/更改资源，我一直非常恼火。
如果你看一下RFC 2616的第55页（“超文本传输协议 - HTTP / 1.1”），Section 9.6（“PUT”），你会看到PUT的实际用途：
PUT方法请求将所包含的实体存储在提供的Request-URI下。
还有一个方便的段落来解释POST和PUT之间的区别：
POST和PUT请求之间的根本区别体现在Request-URI的不同含义上。 POST请求中的URI标识将处理所包含实体的资源。该资源可能是数据接受过程，某些其他协议的网关或接受注释的单独实体。相反，PUT请求中的URI标识请求附带的实体 - 用户代理知道URI的用途，服务器不得尝试将请求应用于其他资源。
它没有提到更新/创建之间的区别，因为这不是它的意义。这是关于这个的区别：
obj.set_attribute(value) # A POST request.
还有这个：
obj.attribute = value # A PUT request.
所以，请停止这种流行的误解的传播。阅读您的RFC。