http - POST 和 PUT HTTP 请求有什么区别？

Question

它们似乎都在向体内的服务器发送数据，那么它们有何不同呢？

score 983 · Accepted Answer

HTTP 放置：

PUT 将文件或资源放在特定的 URI 上，并且准确地放在该 URI 上。如果该 URI 中已有文件或资源，则 PUT 会替换该文件或资源。如果那里没有文件或资源，则 PUT 创建一个。PUT 是幂等的，但矛盾的是 PUT 响应是不可缓存的。

PUT 的 HTTP 1.1 RFC 位置

HTTP 发布：

POST 将数据发送到特定的 URI，并期望该 URI 上的资源来处理请求。此时的 Web 服务器可以确定如何处理指定资源上下文中的数据。POST 方法不是幂等的，但是只要服务器设置适当的 Cache-Control 和 Expires 标头，POST 响应是可缓存的。

官方 HTTP RFC 指定 POST 为：

现有资源的注释；
将消息发布到公告板、新闻组、邮件列表或类似的文章组；
向数据处理过程提供数据块，例如提交表单的结果；
通过追加操作扩展数据库。

POST 的 HTTP 1.1 RFC 位置

POST 和 PUT 的区别：

RFC 本身解释了核心区别：

POST 和 PUT 请求的根本区别体现在 Request-URI 的不同含义上。POST 请求中的 URI 标识将处理封闭实体的资源。该资源可能是一个数据接受进程，一个通往其他协议的网关，或者一个接受注释的单独实体。相比之下，PUT 请求中的 URI 标识了请求中包含的实体——用户代理知道 URI 的意图，服务器不得尝试将请求应用于其他资源。如果服务器希望将请求应用于不同的 URI，它必须发送 301（永久移动）响应；然后用户代理可以自己决定是否重定向请求。

此外，更简洁一点的是，RFC 7231 第 4.3.4 节 PUT状态（强调添加），

4.3.4. 放

PUT 方法请求目标资源的状态是 created或replaced具有由请求消息有效负载中包含的表示定义的状态。

使用正确的方法，不相关的：

REST ROA与 SOAP 相比的一个好处是，在使用 HTTP REST ROA 时，它鼓励正确使用 HTTP 动词/方法。因此，例如，当您想在该确切位置创建资源时，您只会使用 PUT。而且您永远不会使用 GET 来创建或修改资源。

score 237 · Accepted Answer

只有语义。

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

HTTPPOST更通用。它应该在服务器上启动一个动作。该操作可能是将请求正文存储在由 URI 标识的资源中，也可能是不同的 URI，也可能是不同的操作。

PUT就像文件上传。对 URI 的放置完全影响该 URI。对 URI 的 POST 可能会产生任何影响。

score 150 · Accepted Answer

举个 REST 风格资源的例子：

POST /books带有一堆书籍信息可能会创建一本新书，并以标识该书的新 URL 进行响应：/books/5.

PUT /books/5将不得不创建一本 id 为 5 的新书，或者用 ID 5 替换现有的书。

在非资源风格中，POST几乎可以用于任何有副作用的事情。另一个区别是它PUT应该是幂等的 -PUTs同一 URL 的多个相同数据应该没问题，而多个POSTs可能会创建多个对象或您的POST操作所做的任何事情。

score 112 · Accepted Answer

GET：从服务器检索数据。应该没有其他影响。
PUT：用请求有效负载替换目标资源。可用于更新或创建新资源。
PATCH：类似于 PUT，但仅用于更新现有资源中的某些字段。
POST：对有效负载执行特定于资源的处理。可用于不同的操作，包括创建新资源、上传文件或提交 Web 表单。
DELETE：从服务器中删除数据。
TRACE：提供一种测试服务器接收内容的方法。它只是返回发送的内容。
OPTIONS：允许客户端获取有关服务支持的请求方法的信息。相关的响应标头是 Allow with supported methods。也在 CORS 中用作预检请求，以通知服务器实际请求方法并询问自定义标头。
HEAD：仅返回响应标头。
CONNECT：当浏览器知道它与代理通信并且最终的 URI 以 https:// 开头时，它会使用它。CONNECT 的目的是允许端到端加密的 TLS 会话，因此代理无法读取数据。

score 71 · Accepted Answer

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

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

请参阅HTTP RFC

score 47 · Accepted Answer

据我所知，PUT 主要用于更新记录。

POST - 创建文档或任何其他资源
PUT - 更新创建的文档或任何其他资源。

但要明确的是，PUT 通常会“替换”现有记录（如果存在），如果不存在则创建..

score 20 · Accepted Answer

其他人已经发布了很好的答案，我只是想补充一点，对于大多数语言、框架和用例，您POST将比PUT. PUT, DELETE,到了等等基本上都是琐事问题的地步。

score 19 · Accepted Answer

请参阅：http: //zacharyvoase.com/2009/07/03/http-post-put-diff/

我最近对 Web 开发人员的一种流行误解感到非常恼火，即 POST 用于创建资源，而 PUT 用于更新/更改资源。

如果您查看 RFC 2616（“超文本传输协议 – HTTP/1.1”）第 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。

score 19 · Accepted Answer

根据 HTTP 方法定义操作

HTTP 协议定义了许多为请求分配语义含义的方法。大多数 RESTful Web API 使用的常见 HTTP 方法是：

GET检索指定 URI 处的资源表示。响应消息的正文包含所请求资源的详细信息。

POST在指定的 URI 处创建一个新资源。请求消息的正文提供了新资源的详细信息。请注意，POST 也可用于触发实际上不创建资源的操作。

PUT创建或替换指定 URI 处的资源。请求消息的正文指定要创建或更新的资源。

PATCH执行资源的部分更新。请求正文指定要应用于资源的更改集。

DELETE删除指定 URI 处的资源。

特定请求的效果应取决于资源是集合还是单个项目。下表使用电子商务示例总结了大多数 RESTful 实现所采用的常见约定。并非所有这些请求都可以实现——这取决于具体的场景。

资源	邮政	得到	放	删除
/顾客	创建新客户	检索所有客户	批量更新客户	删除所有客户
/客户/1	错误	检索客户 1 的详细信息	更新客户 1 的详细信息（如果存在）	删除客户 1
/客户/1/订单	为客户 1 创建新订单	检索客户 1 的所有订单	批量更新客户 1 的订单	删除客户 1 的所有订单

POST、PUT 和 PATCH 之间的区别可能令人困惑。

POST请求创建一个资源。服务器为新资源分配一个 URI 并将该 URI 返回给客户端。在中REST model，您经常将POST请求应用于集合。新资源将添加到集合中。POST请求也可用于向现有资源提交数据以进行处理，而无需创建任何新资源。

PUT请求创建资源或更新现有资源。客户端指定资源的 URI。请求正文包含资源的完整表示。如果具有此 URI 的资源已存在，则将其替换。否则，如果服务器支持这样做，则会创建一个新资源。PUT请求最常应用于作为单个项目的资源，例如特定客户，而不是集合。服务器可能支持更新，但不支持通过PUT. 是否支持创建 viaPUT取决于客户端是否可以在资源存在之前有意义地将 URI 分配给资源。如果没有，则用于POST创建资源和PUT or PATCH更新。

PATCH请求对现有资源执行部分更新。客户端指定资源的 URI。请求正文指定要应用于资源的一组更改。这可能比 using 更有效PUT，因为客户端只发送更改，而不是资源的整个表示。如果服务器支持，从技术上讲PATCH也可以创建一个新资源（通过指定一组对“空”资源的更新）。

PUT请求必须是幂等的。PUT如果一个客户端多次提交相同的请求，结果应该总是相同的（相同的资源将被修改为相同的值）。POST and PATCH请求不保证是幂等的。

score 13 · Accepted Answer

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

score 12 · Accepted Answer

何时使用其中一个应该非常简单，但复杂的措辞是我们许多人混淆的根源。

何时使用它们：

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”标识的报表信息

score 5 · Accepted Answer

POST 和 PUT 的区别在于 PUT 是幂等的，也就是说，多次调用同一个 PUT 请求总是会产生相同的结果（即没有副作用），而另一方面，重复调用一个 POST 请求可能有（附加）多次创建相同资源的副作用。

GET：使用 GET 的请求只检索数据，即它请求指定资源的表示

POST：它将数据发送到服务器以创建资源。请求正文的类型由 Content-Type 标头指示。它通常会导致服务器的状态变化或副作用

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

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

DELETE: 删除指定资源

TRACE：它沿着到目标资源的路径执行消息环回测试，提供有用的调试机制

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

HEAD：它要求与 GET 请求相同的响应，但没有响应正文

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

score 4 · Accepted Answer

值得一提的POST是，它会受到一些常见的跨站点请求伪造 (CSRF) 攻击，而PUT并非如此。

当受害者访问时，下面的 CSRF 是不可能PUTattackersite.com的。

攻击的效果是受害者无意中删除了一个用户，只是因为它（受害者）在访问之前以adminon登录：target.site.comattackersite.com

恶意代码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，需要更进一步，在发出实际请求之前请求服务器的许可[..]所谓的预检请求 [..]

score 4 · Accepted Answer

用简单的话你可以说：

1.HTTP Get：用于获取一项或多项

2.HTTP Post：用于创建项目

3.HTTP Put：用于更新一个item

4.HTTP Patch：用于部分更新一个item

5.HTTP Delete：用于删除一个item

score 3 · Accepted Answer

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 风格的另一个区别

POSTis Non-Idempotent Operation：同一个请求多次执行会导致一些变化。

PUT是幂等操作：同一个请求多次执行不会有副作用。

score 2 · Accepted Answer

其实除了头衔之外没有什么区别。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 方法，您没有任何限制，并且您的内容不需要以任何方式更改或操作。

score 1 · Accepted Answer

概括

用于使用请求中包含的表示定义PUT的状态来创建或替换目标资源的状态。这种标准化的预期效果是幂等的，因此它通知中介他们可以在通信失败的情况下重复请求。
以其他方式使用POST（包括创建或替换目标资源以外的资源的状态）。它的预期效果没有标准化，因此中介不能依赖任何普遍的财产。

参考

RFC 7231 (Roy Fielding, Julian Reschke, 2014)中给出了关于 thePOST和PUTrequest 方法之间语义差异的最新权威描述：

POST和方法之间的根本区别在于PUT封闭表示的不同意图。请求中的目标资源POST旨在根据资源自身的语义处理封闭的表示，而PUT请求中的封闭表示被定义为替换目标资源的状态。因此，intent 的意图PUT是幂等的并且对中介可见，即使确切的效果只有源服务器知道。

换句话说，预期效果PUT是标准化的（使用请求中包含的表示定义的状态创建或替换目标资源的状态），因此对所有目标资源都是通用的，而预期效果POST不是标准化的，并且所以特定于每个目标资源。因此POST可以用于任何事情，包括实现PUT和其他请求方法（GET、HEAD、DELETE、CONNECT、OPTIONS和TRACE）的预期效果。

但建议始终使用更专业的请求方法，而不是POST在适用的情况下，因为它为中介提供更多信息以自动检索信息（因为GET、HEAD、OPTIONS和TRACE被定义为安全的）、处理通信故障（因为GET、HEAD、PUT、DELETE、OPTIONS和TRACE被定义为idempotent），并优化缓存性能（因为GET和HEAD被定义为cacheable），如使用 POST 可以（Roy Fielding，2009）中所述：

POST只有在其他方法非常适合的情况下使用它才会成为问题：例如，检索应该是某种资源的表示的信息 ( GET)、完全替换表示 ( PUT) 或任何其他标准化告诉中间人一些比“这可能会改变一些事情”更有价值的方法。其他方法对中介更有价值，因为它们说明了如何自动处理故障以及中间缓存如何优化它们的行为。POST没有这些特征，但这并不意味着我们可以没有它。POST在 HTTP 中有许多有用的用途，包括“此操作不值得标准化”的一般用途。</p>

score 0 · Accepted Answer

PUT 和 POST 都是 Rest Methods 。

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

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

每次使用相同参数的 POST 进行相同的调用会导致两种不同的事情发生，因此为什么 POST 通常用于 Create 场景

score 0 · Accepted Answer

Post 和 Put 主要用于发布数据和其他更新数据。但是您只能对发布请求执行相同的操作。

http - POST 和 PUT HTTP 请求有什么区别？

19 回答 19

何时使用它们：

一般来说：

例子：

概括

参考

Related

Reference