背景信息分析:
根据 RFC 2616,第 9.5 条,POST 用于创建资源:
使用 POST 方法要求原始服务器接受请求中包含的实体作为请求-URI 在请求线中识别的资源的新子属。
根据 RFC 2616,第 9.6 条,PUT 用于创建或取代资源:
PUT 方法要求关闭的实体存储在提供的请求-URI. 如果请求-URI 提到已经存在的资源,关闭的实体 SHOULD 将被视为居住在原始服务器的修改版本. 如果请求-URI 没有指向现有资源,并且 URI 能够由请求用户年龄定义为新资源。
我的问题:
那么,哪种HTTP方法应该用于创建资源?或者两者都应该得到支持?
当前回答
或者你可以这样做:考虑你的不安全的请求作为一个极端的单用户资源(让我们称之为行动)。客户要求一个新的“行动”在一个有意义的资源与一个空的POST到资源。
在告诉我这不是RESTful之前,请考虑遵守REST原则的众多方式. 客户不构建URL. API 仍然可发现,尽管在语法中有点变化. HTTP 字母被适当使用. 如果你认为这是一个巨大的变化来实施,我可以从经验中告诉你,这不是。
其他回答
邮件 vs 邮件
邮件
http://example.com/form
http://example.com/form/568
PUT需要知道这个地址点给一个实体!
http://example.com/097243523581549126143698
您是否知道过去 20+ 年内浏览器中的 HTML 表格方法属性仅支持 POST 和 GET,并且不支持 PUT?
POST and GET work ok...
<form id="form1" name="form1" method="get" action="/form">...</form>
<form id="form2" name="form2" method="post" action="/form">...</form>
PUT NOT SUPPORTED!
<form id="form3" name="form3" method="put" action="/form">...</form>
DELETE NOT SUPPORTED!
<form id="form4" name="form4" method="delete" action="/form">...</form>
疯了啊?
然后,服务器必须仔细观察这个URL(加上按下“添加”,“删除”,“更新”等任何按钮)决定什么是正确的字母,然后路由POST或PUT或DELETE等到正确的服务器处理器。
事实上,PUT一直连接到URL识别器,而不是您的客户端侧代码的逻辑,但它是当今客户端侧模型的错误性质,其破碎的HTML5设计,加上当今厚客户端JavaScript API呼叫和其他循环技巧的腐败性质,这些技巧污染了应该是一个非常简单的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 如发送邮件在邮局。
此分類上一篇
社交媒体/网络分析:
社交媒体上的帖子:当我们发布消息时,它会创建新的帖子(即编辑)我们已经发布的帖子。
您应该使用 PATCH. 您应该使用 PATCH 等问题列表
PATCH /questions HTTP/1.1
包含您要创建的对象的列表,如
[
{
"title": "I said semantics!",
"content": "Is this serious?",
"answer": "Not really"
}
]
您将修改现有资源列表,而无需提供全新的内容,您将从不存在的数据转换为现有信息的状态,而无需提供所有数据(服务器最有可能将添加身份证)。
这个方法的一个很好的优点是,您可以使用单个请求创建多个实体,简单地将所有实体列入列表中。
一个缺点是,可能没有人这样使用PATCH,我害怕,我只是发明了它,但我希望,我提供了一个很好的论点。
至于语法,CREATE是IMHO的唯一正确选择,其余的一切都是一个圆洞的平方点,不幸的是,我们所有的都是圆洞。
简而言之:
分析与数据库查询
PUT 您可以想象类似于“UPDATE STUDENT SET 地址 = “abc” 在 id="123”;
在 POST 案例中,如果同一查询多次执行,则在数据库中创建了多个学生记录,数据库状态在每个“INSERT”查询的执行时都会发生变化。
注意: PUT 需要一个资源位置(现有资源),更新需要发生,而 POST 则不需要这样做。
有些人可能會發現這些更新可以用 POST 進行. 沒有嚴格的規則,哪一個要用於更新或哪一個要用於創造。
在恢复已经提到的风险下,似乎很重要的是要记住,PUT意味着客户端在创建资源时会控制什么URL。因此,PUT和POST之间的选择的一部分将是关于您可以信任客户端提供正确的,正常的URL,与您的URL计划是什么相一致。
当您无法完全信任客户端做正确的事情时,更适合使用 POST 创建一个新的项目,然后将 URL 返回客户端在回复中。
