背景信息分析:
根据 RFC 2616,第 9.5 条,POST 用于创建资源:
使用 POST 方法要求原始服务器接受请求中包含的实体作为请求-URI 在请求线中识别的资源的新子属。
根据 RFC 2616,第 9.6 条,PUT 用于创建或取代资源:
PUT 方法要求关闭的实体存储在提供的请求-URI. 如果请求-URI 提到已经存在的资源,关闭的实体 SHOULD 将被视为居住在原始服务器的修改版本. 如果请求-URI 没有指向现有资源,并且 URI 能够由请求用户年龄定义为新资源。
我的问题:
那么,哪种HTTP方法应该用于创建资源?或者两者都应该得到支持?
当前回答
两者都用于客户端到服务器之间的数据传输,但它们之间存在微妙的差异,即:
| PUT | POST |
|---|---|
Replacing existing resource or creating if resource is not exist. www.example.com/com/customer/{customerId} www.example.com/com/customer/123/order/{orderId} Identifier is chosen by the client. |
Creating new resources and subordinate resources, e.g. a file is subordinate to a directory containing it or a row is subordinate to a database table. www.example.com/com/customer/ www.example.com/com/customer/123/order/ identifier is returned by server |
Idempotent i.e. if you PUT a resource twice, it has no effect. Example: Do it as many times as you want, the result will be same. x=1; |
POST is neither safe nor idempotent. Example: x++; |
| Works as specific | Works as abstractive |
If you create or update a resource using PUT and then make that same call again, the resource is still there and still has the same state as it did with the first call. |
Making two identical POST requests will most likely result in two resources containing the same information. |
类似:
PUT 即采取并放置它在哪里. POST 如发送邮件在邮局。
此分類上一篇
社交媒体/网络分析:
社交媒体上的帖子:当我们发布消息时,它会创建新的帖子(即编辑)我们已经发布的帖子。
其他回答
简短答案:
简单的规则:使用 POST 创建,使用 PUT 更新。
长答:
邮件:
POST 用于向服务器发送数据,当资源的 URL 未知时有用
皮特:
PUT 用于将状态转移到使用的服务器,当资源的 URL 已知时
更长的答案:
要了解它,我们需要质疑为什么PUT是必要的,什么问题PUT试图解决POST不能。
从REST架构的角度来看,这并不重要,我们也可能没有PUT,但从客户开发者的角度来看,它使他的生活更简单。
在PUT之前,客户无法直接知道服务器所产生的URL,或者如果它全部产生的URL,或者是否要发送到服务器的数据已经更新了,PUT缓解了所有这些头痛的开发者。
使用 POST 创建,而 PUT 更新,这就是 Ruby on Rails 如何做到这一点。
PUT /items/1 #=> update
POST /items #=> create
PUT 是用于创建或替换客户端所知道的 URL 的资源。
因此: PUT 仅是 CREATE 的候选人,客户在创建资源之前已经知道 URL。 /blogs/nigel/entry/when_to_use_post_vs_put 因为标题被用作资源密钥
RFC 如下:
注意: PUT 主要用于更新资源(通过将其全部替换为资源),但最近出现了使用 PATCH 来更新现有资源的动作,因为 PUT 说明它取代了整个资源。
從 REST API 設計 - 資源模型 Prakash Subramaniam of Thoughtworks
这迫使API避免多个客户更新一个资源的国家过渡问题,并且更顺利地与事件来源和CQRS相匹配。
除了其他人提出的差异之外,我想添加另一个。
在 POST 方法中,您可以在表格数据中发送身体参数
在 PUT 方法中,您必须在 x-www-form-urlencoded 中发送身体参数
标题内容类型:应用程序/x-www-form-urlencoded
因此,您不能在 PUT 方法中发送文件或多部分数据。
编辑
内容类型“应用/x-www-form-urlencoded”是不有效的发送大量的二进制数据或包含非ASCII字符的文本. 内容类型“多部分/形式数据”应用于提交包含文件、非ASCII数据和二进制数据的表格。
如果你要提交的话
文件,非ASCII数据,和二进制数据
你应该使用邮政方法。
POST 意思是“创建新”如在“这里是创建用户的输入,为我创建它”。
PUT 的意思是“输入,如果已经存在,取代”如“这里是用户数据5”。
您 POST 到 example.com/users 因为您还不知道用户的 URL,您希望服务器创建它。
您可以访问 example.com/users/id 因为您想要更换/创建一个特定的用户。
与相同数据两次发布意味着创建两个相同的用户与不同的ID。 与相同数据两次发布会创建用户的第一个,并更新到相同状态的第二次(没有变化)。 因为你结束相同状态后一个 PUT 无论你执行多少次,它被说是“平等强大”每次 - idempotent. 这是有用的自动退休
