背景信息分析:
根据 RFC 2616,第 9.5 条,POST 用于创建资源:
使用 POST 方法要求原始服务器接受请求中包含的实体作为请求-URI 在请求线中识别的资源的新子属。
根据 RFC 2616,第 9.6 条,PUT 用于创建或取代资源:
PUT 方法要求关闭的实体存储在提供的请求-URI. 如果请求-URI 提到已经存在的资源,关闭的实体 SHOULD 将被视为居住在原始服务器的修改版本. 如果请求-URI 没有指向现有资源,并且 URI 能够由请求用户年龄定义为新资源。
我的问题:
那么,哪种HTTP方法应该用于创建资源?或者两者都应该得到支持?
当前回答
大多数时候,你会用它们如下:
POST a resource into a collection PUT a resource identified by collection/:id。
例如:
POST /items PUT /items/1234
请注意,POST在收藏中“创建”一个新的元素,而PUT在某个URL中“替换”一个元素,但使用PUT进行部分修改是一种非常常见的做法,也就是说,只使用它来更新现有资源,并仅修改体内所包含的字段(忽略其他字段)。
请记住,REST是一组条约和指导方针,以保持您的API简单。 如果您结束了一个复杂的工作周围,只需检查“RESTfull”框,那么您正在击败目的。
其他回答
添加到上面的所有答案:
在职业生涯中最常用的
我们使用 PUT over POST 在 CREATE 操作中. 为什么? 因为很多在这里也说,答案是不可隐藏的,而 POST 是(要求内容位置和终止)。 我们使用 POST over PUT 在 UPDATE 操作中. 为什么? 因为它破坏了整个包含资源的隐藏副本. 这是有用的,当更新资源。
我喜欢这个建议,从RFC 2616的定义PUT:
我解释了这一点,以及PUT的身份要求,这意味着:
POST 很好在收藏下创建新的对象(而创建不需要是同效的) PUT 很好在更新现有对象(而更新需要是同效的) POST 也可以用于对现有对象的非同效的更新(特别是,改变对象的一部分,而不说明整个事物 - 如果你想到它,创建一个新成员的收藏实际上是
最重要的考虑是可靠性. 如果一个 POST 消息丢失,系统的状态是不确定的. 自动恢复是不可能的. 对于 PUT 消息,状态是不确定的,直到第一次成功退出。
例如,使用 POST 创建信用卡交易可能不是一个好主意。
如果您在您的资源上有自动创建的 URI,您仍然可以使用 PUT 通过向客户端传输一个创建的 URI(指向一个空的资源)。
其他一些考虑:
POST 取消了所有包含资源的隐藏副本(更好的一致性) PUT 回复是不可隐藏的,而 POST 回复是(要求内容位置和终止) PUT 是不受 Java ME、旧浏览器、防火墙等支持。
这里是一个简单的规则:
到一个 URL 的 PUT 应该用于更新或创建可以位于该 URL 的资源。
POST to a URL should be used to update or create a resource that is located at some other ("subordinate") URL, or is not locatable via HTTP. URL 应该用于更新或创建位于某个其他(“下级”) URL 或无法通过 HTTP 找到的资源。
POST 可以执行其他三项功能,但随后请求的语法将失去在中间人,如Caches 和 Proxy. 这也适用于提供资源的安全性,因为一个帖子的 URI 不一定指示它正在应用的资源(但它可以)。
编辑: 另一个事情 - 一个 PUT 可以创建,但如果这样做,那么 ID 必须是一个自然 ID - AKA 一个电子邮件地址。
