POST和PUT HTTP REQUEST有什么区别？

Question

他们似乎都在向身体内的服务器发送数据,那么是什么让他们与众不同呢？

Answer 1

HTTP PUT:

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

PUT的HTTP 1.1 RFC位置

HTTP POST:

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标识将处理所包含实体的资源.该资源可能是数据接受过程,某些其他协议的网关或接受注释的单独实体.与此相反,在URI的PUT请求识别附带请求的实体 - 用户代理知道URI打算和服务器不能尝试应用请求一些其他的资源.如果服务器希望将请求应用于不同的URI,它必须发送301(永久移动)响应; 然后,用户代理可以自己决定是否重定向请求.

使用正确的方法,无关:

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

Answer 2

只有语义.

HTTP PUT应该接受请求的主体,然后将其存储在URI标识的资源中.

HTTP POST更通用.它应该在服务器上启动一个动作.该操作可以是将请求主体存储在由URI标识的资源中,或者它可以是不同的URI,或者它可以是不同的动作.

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

Answer 3

举例说明REST风格的资源:

带有大量图书信息的"POST/books"可能会创建一本新书,并使用标识该书的新URL进行回复:"/ books/5".

"PUT/books/5"必须创建id为5的新书,或者用ID 5替换现有书籍.

在非资源风格中,POST可以用于任何具有副作用的东西.另一个区别是PUT应该是幂等的 - 相同URL的相同数据的多个PUT应该没问题,而多个POST可能会创建多个对象或者你的POST操作.

Answer 4

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

另一方面,POST是一种提交与给定URI相关的数据的方法.

请参阅HTTP RFC

Answer 5

据我所知,PUT主要用于更新记录.

1. POST - 创建文档或任何其他资源

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

但是要明确PUT通常会"替换"现有记录(如果它存在)并创建它是否存在...

Answer 6

1. GET:从服务器检索数据.应该没有其他影响.
2. POST:将数据发送到服务器以创建新实体.通常在上传文件或提交网络表单时使用.
3. PUT:与POST类似,但用于替换现有实体.
4. 补丁:与PUT类似,但仅用于更新现有实体中的某些字段.
5. DELETE:从服务器中删除数据.
6. TRACE:提供测试服务器接收的方法.它只返回发送的内容.
7. 选项:允许客户端获取有关服务支持的请求方法的信息.相关的响应标头是Allow with supported methods.还在CORS中用作预检请求,以通知服务器有关实际请求方法并询问自定义标头.
8. HEAD:仅返回响应头.
9. CONNECT:当浏览器知道它与代理进行通信并且最终的URI以https://开头时由浏览器使用.CONNECT的目的是允许端到端加密的TLS会话,因此数据对代理是不可读的.

Answer 7

其他人已经发布了很好的答案,我只想添加大多数语言,框架和用例,你将会比PUT更频繁地处理POST.到PUT,DELETE等基本上是琐事问题.

Answer 8

何时使用一种或另一种应该非常简单，但复杂的措辞让我们许多人感到困惑。

何时使用它们：

• 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”删除报告

Answer 9

POST被认为是工厂类型的方法.您可以在其中包含数据以创建您想要的内容,而另一端则知道如何处理它.PUT用于更新给定URL的现有数据,或者当您知道URI将会是什么并且它尚不存在时创建新的东西(而不是POST将创建一些东西并返回一个URL到如有必要).

Answer 10

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

最近,网络开发人员普遍误以为使用POST来创建资源,而PUT用于更新/更改资源,我一直非常恼火.

如果您查看RFC 2616的第55页("超文本传输​​协议 - HTTP/1.1"),第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.

Answer 11

REST要求开发人员以与协议定义一致的方式显式地使用HTTP方法.这个基本的REST设计原则在创建,读取,更新和删除(CRUD)操作和HTTP方法之间建立了一对一的映射.根据这个映射:

•要在服务器上创建资源,请使用POST.

•要检索资源,请使用GET.

•要更改资源的状态或更新资源,请使用PUT.

•要删除或删除资源,请使用DELETE.

更多信息: RESTful Web服务:IBM的基础知识

Answer 12

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

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

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

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

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

DELETE : 删除指定资源

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

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

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

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

Answer 13

值得一提的是，它POST会受到一些常见的跨站点请求伪造（CSRF）攻击，而PUT不会。

\n

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

\n

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

\n

恶意代码attackersite.com：

\n

情况1：正常请求。保存的target.site.comcookie将自动由浏览器发送：（注意：PUT仅在端点支持更安全，因为它不是受支持的<form>属性值）

\n

<!--deletes user with id 5-->\n<form id="myform" method="post" action="http://target.site.com/deleteUser" >\n    <input type="hidden" name="userId" value="5">\n</form>\n<script>document.createElement(\'form\').submit.call(document.getElementById(\'myform\'));</script>\n

\n

情况 2： XHR 请求。保存的target.site.comcookie将由浏览器自动发送：（注意：PUT仅在端点支持更安全，因为尝试发送PUT将触发预检请求，其响应将阻止浏览器请求页面deleteUser）

\n

//deletes user with id 5\nvar xhr = new XMLHttpRequest();\nxhr.open("POST", "http://target.site.com/deleteUser");\nxhr.withCredentials=true;\nxhr.send(["userId=5"]);\n

\n

\n

MDN 参考：[..]与 \xe2\x80\x9csimple requests\xe2\x80\x9d （上面讨论的）不同，--[[ 表示：POST/GET/HEAD ]]--，对于“预检”请求首先浏览器使用 OPTIONS 方法发送 HTTP 请求[..]

\n

\n

\n

cors 的实际应用：[..]某些类型的请求，例如 DELETE 或 PUT，需要更进一步，在发出实际请求之前请求 server\xe2\x80\x99s 权限[..]所谓的飞行前请求[..]

\n

\n

Answer 14

用简单的话来说，你可以说：

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

2.HTTP Post：用于创建一个item

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

4.HTTP Patch：用于部分更新项目

5.HTTP删除：用于删除一个项目