背景信息分析:
根据 RFC 2616,第 9.5 条,POST 用于创建资源:
使用 POST 方法要求原始服务器接受请求中包含的实体作为请求-URI 在请求线中识别的资源的新子属。
根据 RFC 2616,第 9.6 条,PUT 用于创建或取代资源:
PUT 方法要求关闭的实体存储在提供的请求-URI. 如果请求-URI 提到已经存在的资源,关闭的实体 SHOULD 将被视为居住在原始服务器的修改版本. 如果请求-URI 没有指向现有资源,并且 URI 能够由请求用户年龄定义为新资源。
我的问题:
那么,哪种HTTP方法应该用于创建资源?或者两者都应该得到支持?
当前回答
在很简单的方式,我正在采取Facebook时间线的例子。
案例1:当你在时间表上发布某些东西时,这是一个新鲜的新输入,所以在这种情况下,他们使用POST方法,因为POST方法是无效的。
案例2:如果你的朋友第一次评论你的帖子,它也会在数据库中创建一个新的帖子,以便使用POST方法。
案例3:如果你的朋友编辑他的评论,在这种情况下,他们有一个评论 ID,所以他们将更新一个现有评论而不是创建一个新的数据库输入。
在单行中,使用 POST 在数据库中添加一个新的输入和 PUT 在数据库中更新一些东西。
其他回答
我喜欢这个建议,从RFC 2616的定义PUT:
我解释了这一点,以及PUT的身份要求,这意味着:
POST 很好在收藏下创建新的对象(而创建不需要是同效的) PUT 很好在更新现有对象(而更新需要是同效的) POST 也可以用于对现有对象的非同效的更新(特别是,改变对象的一部分,而不说明整个事物 - 如果你想到它,创建一个新成员的收藏实际上是
您可以在网页上找到声明说
也不是很正确。
最好选择 PUT 和 POST 之间,基于行动的可行性。
PUT 意味着放置一个资源 - 完全取代在特定 URL 上可用的任何东西与不同的东西. 根据定义,一个 PUT 是无能为力. 尽量尽量多次,结果是相同的. x=5 是无能为力. 你可以 PUT 一个资源,无论它以前存在,还是不存在(例如,创建,或更新)!
POST 更新一个资源,添加一个子资源,或引发一个变化. 一个 POST 不是 idempotent,因此 x++ 不是 idempotent。
根据这个论点,PUT是为了创建,当你知道你将创建的东西的URL。POST可以用来创建,当你知道“工厂”的URL或管理者为你想要创建的东西类别。
如:
POST /expense-report
或:
PUT /expense-report/10929
添加到上面的所有答案:
在职业生涯中最常用的
我们使用 PUT over POST 在 CREATE 操作中. 为什么? 因为很多在这里也说,答案是不可隐藏的,而 POST 是(要求内容位置和终止)。 我们使用 POST over PUT 在 UPDATE 操作中. 为什么? 因为它破坏了整个包含资源的隐藏副本. 这是有用的,当更新资源。
对于我来说,了解区别的关键是了解谁定义资源的ID:
例子(与某些地址服务)
POST (sever creates new resource)
client server/addresses // NOTE: no ID in the request
| |
| --{POST address data}--> |
| |
| <--{201, created addresses/321} | // NOTE: resource ID in the reply
| |
PUT (sever sets data of resource, creating it if necessary)
client server/addresses/321 // NOTE: *you* put the ID here!
| |
| --{PUT address data (to 321)}-->|
| |
| <--{201, created } | // NOTE: resource ID not required here
| |
这里有很多很好的答案,下面有很好的细节,但这帮助了我到达这个点。
在恢复已经提到的风险下,似乎很重要的是要记住,PUT意味着客户端在创建资源时会控制什么URL。因此,PUT和POST之间的选择的一部分将是关于您可以信任客户端提供正确的,正常的URL,与您的URL计划是什么相一致。
当您无法完全信任客户端做正确的事情时,更适合使用 POST 创建一个新的项目,然后将 URL 返回客户端在回复中。
