它们似乎都在向体内的服务器发送数据，那么它们有何不同呢？
HTTP 放置：
PUT 将文件或资源放在特定的 URI 上，并且准确地放在该 URI 上。如果该 URI 中已有文件或资源，则 PUT 会替换该文件或资源。如果那里没有文件或资源，则 PUT 创建一个。 PUT 是 idempotent，但矛盾的是 PUT 响应不可缓存。
HTTP 发布：
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（永久移动）响应；然后用户代理可以自己决定是否重定向请求。
此外，更简洁一点的是，RFC 7231 Section 4.3.4 PUT 状态（添加了重点），
4.3.4. PUT PUT 方法请求创建目标资源的状态或将其替换为请求消息有效负载中包含的表示定义的状态。
使用正确的方法，不相关的：
REST ROA 与 SOAP 相比的一个好处是，在使用 HTTP REST ROA 时，它鼓励正确使用 HTTP 动词/方法。因此，例如，当您想在该确切位置创建资源时，您只会使用 PUT。而且您永远不会使用 GET 来创建或修改资源。
只有语义。
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 应该是幂等的：相同数据的多个 PUT 到同一个 URL 应该没问题，而多个 POST 可能会创建多个对象或您的 POST 操作所做的任何事情。
GET：从服务器检索数据。应该没有其他影响。 PUT：用请求有效负载替换目标资源。可用于更新或创建新资源。 PATCH：类似于 PUT，但仅用于更新现有资源中的某些字段。 POST：对有效负载执行特定于资源的处理。可用于不同的操作，包括创建新资源、上传文件或提交 Web 表单。 DELETE：从服务器中删除数据。 TRACE：提供一种测试服务器接收内容的方法。它只是返回发送的内容。选项：允许客户端获取有关服务支持的请求方法的信息。相关的响应标头是 Allow with supported methods。在 CORS 中也用作预检请求，以通知服务器实际的请求方法并询问自定义标头。 HEAD：仅返回响应标头。 CONNECT：当浏览器知道它与代理通信并且最终的 URI 以 https:// 开头时，由浏览器使用。 CONNECT 的目的是允许端到端加密的 TLS 会话，因此代理无法读取数据。
据我所知，PUT 主要用于更新记录。
POST - 创建文档或任何其他资源 PUT - 更新创建的文档或任何其他资源。
但要明确的是，PUT 通常会“替换”现有记录（如果存在），如果不存在则创建..
Define operations in terms of HTTP methods
HTTP 协议定义了许多为请求分配语义含义的方法。大多数 RESTful Web API 使用的常见 HTTP 方法是：
GET 检索指定 URI 处的资源表示。响应消息的正文包含所请求资源的详细信息。
POST 在指定的 URI 处创建一个新资源。请求消息的正文提供了新资源的详细信息。请注意，POST 也可用于触发实际上不创建资源的操作。
PUT 创建或替换指定 URI 处的资源。请求消息的正文指定要创建或更新的资源。
PATCH 执行资源的部分更新。请求正文指定要应用于资源的更改集。
DELETE 删除指定 URI 处的资源。
特定请求的效果应取决于资源是集合还是单个项目。下表使用电子商务示例总结了大多数 RESTful 实现所采用的常见约定。并非所有这些请求都可以实现——这取决于具体的场景。
资源 POST GET PUT DELETE /customers 创建一个新客户 检索所有客户 批量更新客户 删除所有客户 /customers/1 错误 检索客户 1 的详细信息 更新客户 1 的详细信息（如果存在） 删除客户 1 /customers/1/orders为客户 1 创建新订单 检索客户 1 的所有订单 批量更新客户 1 的订单 删除客户 1 的所有订单
POST、PUT 和 PATCH 之间的区别可能令人困惑。
POST 请求创建一个资源。服务器为新资源分配一个 URI 并将该 URI 返回给客户端。在 REST model 中，您经常将 POST 请求应用于集合。新资源将添加到集合中。 POST 请求还可用于向现有资源提交数据以进行处理，而无需创建任何新资源。
PUT 请求创建资源或更新现有资源。客户端指定资源的 URI。请求正文包含资源的完整表示。如果具有此 URI 的资源已存在，则将其替换。否则，如果服务器支持这样做，则会创建一个新资源。 PUT 请求最常应用于作为单个项目的资源，例如特定客户，而不是集合。服务器可能支持更新但不支持通过 PUT 创建。是否支持通过 PUT 创建取决于客户端是否可以在资源存在之前将 URI 有意义地分配给资源。如果没有，则使用 POST 创建资源并使用 PUT or PATCH 进行更新。
PATCH 请求对现有资源执行部分更新。客户端指定资源的 URI。请求正文指定要应用于资源的一组更改。这可能比使用 PUT 更有效，因为客户端只发送更改，而不是资源的整个表示。从技术上讲，PATCH 还可以创建一个新资源（通过指定一组对“空”资源的更新），如果服务器支持的话。
PUT 请求必须是幂等的。如果客户端多次提交相同的 PUT 请求，结果应该始终相同（相同的资源将被修改为相同的值）。 POST and PATCH 请求不保证是幂等的。
其他人已经发布了出色的答案，我只是想补充一点，对于大多数语言、框架和用例，您将处理 POST 比 PUT 更频繁。到PUT, DELETE,等基本上是琐事问题的地步。
请参阅：http://zacharyvoase.com/2009/07/03/http-post-put-diff/
我最近对 Web 开发人员的一种流行误解感到非常恼火，即 POST 用于创建资源，而 PUT 用于更新/更改资源。
如果您查看 RFC 2616（“超文本传输协议 – HTTP/1.1”）、Section 9.6（“PUT”）的第 55 页，您会看到 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。
POST 被认为是一种工厂类型的方法。您在其中包含数据以创建您想要的内容，而另一端的任何内容都知道如何处理它。 PUT 用于更新给定 URL 处的现有数据，或者在您知道 URI 将是什么但它不存在时创建新的东西（与 POST 相反，它将创建一些东西并返回一个 URL 到如有必要）。
何时使用其中一个应该非常简单，但复杂的措辞是我们许多人混淆的根源。
何时使用它们：
当您想要修改已经是资源集合一部分的单一资源时，请使用 PUT。 PUT 完全替换资源。示例：PUT /resources/:resourceId 旁注：如果要更新资源的一部分，请使用 PATCH。
如果要在资源集合下添加子资源，请使用 POST。示例：POST => /resources
一般来说：
通常，在实践中，始终使用 PUT 进行 UPDATE 操作。
始终使用 POST 进行 CREATE 操作。
例子：
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} => 按“id”删除报告
POST 和 PUT 的区别在于 PUT 是幂等的，也就是说，多次调用同一个 PUT 请求总是会产生相同的结果（即没有副作用），而另一方面，重复调用一个 POST 请求可能有（附加）多次创建相同资源的副作用。
GET：使用 GET 的请求只检索数据，即它请求指定资源的表示
POST ：它将数据发送到服务器以创建资源。请求正文的类型由 Content-Type 标头指示。它通常会导致服务器的状态变化或副作用
PUT ：创建新资源或用请求负载替换目标资源的表示
PATCH ：用于对资源应用部分修改
DELETE : 删除指定资源
TRACE：它沿着到目标资源的路径执行消息环回测试，提供有用的调试机制
OPTIONS : 用于描述目标资源的通信选项，客户端可以为 OPTIONS 方法指定一个 URL，或者星号 (*) 表示整个服务器。
HEAD ：它要求与 GET 请求相同的响应，但没有响应正文
CONNECT ：建立到目标资源标识的服务器的隧道，可用于访问使用 SSL (HTTPS) 的网站
用简单的话你可以说：
1.HTTP Get：用于获取一项或多项
2.HTTP Post：用于创建项目
3.HTTP Put：用于更新一个item
4.HTTP Patch：用于部分更新一个item
5.HTTP Delete：用于删除一个item
值得一提的是，POST 会受到一些常见的跨站请求伪造 (CSRF) 攻击，而 PUT 则不会。
当受害者访问 attackersite.com 时，下面的 CSRF 不可能使用 PUT。
攻击的影响是受害者无意中删除了用户，因为它（受害者）在 target.site.com 上以 admin 的身份登录，然后访问 { 3}：
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 会触发预检请求，其响应会阻止浏览器请求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 in action : [..]某些类型的请求，例如 DELETE 或 PUT，需要更进一步，在发出实际请求之前请求服务器的许可[..]所谓的预检请求 [..]
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 将返回新的资源标识符
非 REST-ful 用法
POST 用于在服务器端发起一个动作，这个动作可能会也可能不会创建一个资源，但是这个动作总会有副作用它会改变服务器上的某些东西
PUT 用于在特定 URL 处放置或替换文字内容
REST-ful 和非 REST-ful 风格的另一个区别
POST 是非幂等操作：同一个请求多次执行会导致一些变化。
PUT 是幂等操作：同一个请求多次执行不会有副作用。
其实除了头衔之外没有什么区别。 GET 和其他方法之间实际上有一个基本的区别。使用“GET”-Request 方法，您在 url-address-line 中发送数据，这些数据首先用问号分隔，然后用 & 符号分隔。
但是使用“POST”请求方法，您不能通过 url 传递数据，但您必须将数据作为所谓的请求“正文”中的对象传递。在服务器端，您必须读出接收到的内容的主体，以获取发送的数据。但是另一方面，当您发送“GET”请求时，不可能在正文中发送内容。
声称“GET”仅用于获取数据而“POST”用于发布数据的说法是绝对错误的。根据“GET”请求或“POST”请求发送的数据，没有人可以阻止您创建新内容、删除现有内容、编辑现有内容或在后端执行任何操作。没有人可以阻止您以某种方式对后端进行编码，即通过“POST”请求，客户端要求一些数据。
有了一个请求，无论你使用哪种方法，你调用一个 URL 并发送或不发送一些数据来指定，你想将哪些信息传递给服务器来处理你的请求，然后客户端从那里得到答案服务器。数据可以包含您想要发送的任何内容，允许后端对数据执行任何操作，并且响应可以包含您想要放入其中的任何信息。
只有这两种基本方法。获取和发布。但正是它们的结构使它们与众不同，而不是您在后端编写的代码。在后端，您可以使用接收到的数据编写任何您想要的代码。但是对于“POST”请求，您必须在正文中而不是在 url-addressline 中发送/检索数据，对于“GET”请求，您必须在 url-addressline 中发送/检索数据而不是在身体。就这样。
所有其他方法，如“PUT”、“DELETE”等，它们的结构与“POST”相同。
主要使用 POST 方法，如果你想隐藏一些内容，因为无论你在 url-addressline 中写入什么，它都会保存在缓存中，并且 GET-Method 与将数据写入 url-addressline 相同。因此，如果您想发送敏感数据，不一定是用户名和密码，而是例如一些您不希望在 url-address-line 中显示的 id 或哈希，那么您应该使用 POST 方法.
此外，URL-Addressline 的长度限制为 1024 个符号，而“POST”方法不受限制。因此，如果您有大量数据，您可能无法使用 GET-Request 发送它，但您需要使用 POST-Request。所以这也是 POST 请求的另一个优点。
但是，当您没有要发送的复杂文本时，处理 GET 请求要容易得多。否则，这是 POST 方法的另一个优点，即使用 GET 方法您需要对文本进行 url 编码，以便能够在文本甚至空格中发送一些符号。但是使用 POST 方法，您没有任何限制，并且您的内容不需要以任何方式更改或操作。
概括
使用 PUT 来创建目标资源的状态或将目标资源的状态替换为请求中包含的表示定义的状态。这种标准化的预期效果是幂等的，因此它通知中介他们可以在通信失败的情况下重复请求。
否则使用 POST（包括创建或替换目标资源以外的资源的状态）。它的预期效果没有标准化，因此中介不能依赖任何普遍的财产。
参考
RFC 7231 中给出了 POST 和 PUT 请求方法之间语义差异的最新权威描述（Roy Fielding，Julian Reschke，2014 年）：
POST 和 PUT 方法之间的根本区别在于封闭表示的不同意图。 POST 请求中的目标资源旨在根据资源自身的语义处理封闭表示，而 PUT 请求中的封闭表示被定义为替换目标资源的状态。因此，PUT 的意图是幂等的并且对中介可见，即使确切的效果只有源服务器知道。
换句话说，PUT 的预期效果是标准化（使用请求中包含的表示定义的状态创建或替换 target 资源的状态）并且so 对所有目标资源都是通用的，而 POST 的预期效果未标准化，因此特定于每个目标资源。因此 POST 可以用于任何事情，包括实现 PUT 和其他请求方法（GET、HEAD、DELETE、CONNECT、OPTIONS 和 TRACE）的预期效果.
但建议在适用时始终使用更专业的请求方法而不是 POST，因为它为中介提供更多信息以自动检索信息（因为定义了 GET、HEAD、OPTIONS 和 TRACE as safe），处理通信故障（因为 GET、HEAD、PUT、DELETE、OPTIONS 和 TRACE 被定义为 幂等），并优化缓存性能（因为 GET 和 HEAD 被定义为 cacheable），如 It Is Okay to Use POST 中所述（Roy Fielding，2009）：
POST 仅在其他方法非常适合的情况下使用时才会成为问题：例如，检索应该是某种资源的表示的信息 (GET)、完全替换表示 (PUT) 或任何其他标准化方法可以告诉中介比“这可能会改变某些事情”更有价值的事情。其他方法对中介更有价值，因为它们说明了如何自动处理故障以及中间缓存如何优化它们的行为。 POST 没有这些特征，但这并不意味着我们可以没有它。 POST 在 HTTP 中有许多有用的用途，包括“此操作不值得标准化”的一般用途。
PUT 和 POST 都是 Rest Methods 。
PUT - 如果我们使用 PUT 两次使用相同的参数发出相同的请求，第二个请求将没有任何效果。这就是为什么 PUT 通常用于 Update 场景的原因，使用相同的参数多次调用 Update 不会比初始调用做更多的事情，因此 PUT 是幂等的。
POST 不是幂等的，例如 Create 将在目标中创建两个单独的条目，因此它不是幂等的，因此 CREATE 在 POST 中被广泛使用。
每次使用相同参数的 POST 进行相同的调用会导致两种不同的事情发生，因此为什么 POST 通常用于 Create 场景
Post 和 Put 主要用于发布数据和其他更新数据。但是您只能对发布请求执行相同的操作。
If the Request-URI does not point to an existing resource [...] the origin server *can* create the resource with that URI。因此，如果 PUT 不存在则拒绝创建资源的实现是正确的，对吗？如果是这样，这在实践中会发生吗？或者实现通常也在 PUT 上创建？