背景信息分析:

根据 RFC 2616,第 9.5 条,POST 用于创建资源:

使用 POST 方法要求原始服务器接受请求中包含的实体作为请求-URI 在请求线中识别的资源的新子属。

根据 RFC 2616,第 9.6 条,PUT 用于创建或取代资源:

PUT 方法要求关闭的实体存储在提供的请求-URI. 如果请求-URI 提到已经存在的资源,关闭的实体 SHOULD 将被视为居住在原始服务器的修改版本. 如果请求-URI 没有指向现有资源,并且 URI 能够由请求用户年龄定义为新资源。

我的问题:

那么,哪种HTTP方法应该用于创建资源?或者两者都应该得到支持?


当前回答

对于我来说,了解区别的关键是了解谁定义资源的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
  |                                 |

这里有很多很好的答案,下面有很好的细节,但这帮助了我到达这个点。

其他回答

大多数时候,你会用它们如下:

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”框,那么您正在击败目的。

使用 POST 创建,而 PUT 更新,这就是 Ruby on Rails 如何做到这一点。

PUT    /items/1      #=> update
POST   /items        #=> create

POST 用于将数据发送到服务器. PUT 用于将数据存入服务器上的资源(例如,文件)。

我看到这一点在一个脚本(第55页)从书HTTP: The Definitive Guide。

总体:

PUT 和 POST 都可以用于创建。

你必须问“你在做什么?”来区分你应该使用什么,假设你正在设计一个API来提出问题,如果你想使用POST,那么你会这样做一个问题列表,如果你想使用PUT,那么你会这样做一个特定的问题。

你不需要支持PUT和POST。

一些考虑:

我写了以下,作为关于此问题的另一个答案的一部分:

POST: 用于修改和更新资源 POST / 问题/<existing_question> HTTP/1.1 主机: www.example.com/ 注意下列是错误: POST / 问题/<new_question> HTTP/1.1 主机: www.example.com/ 如果 URL 尚未创建,您不应该使用 POST 创建它,同时指定名称。

简短答案:

简单的规则:使用 POST 创建,使用 PUT 更新。

长答:

邮件:

POST 用于向服务器发送数据,当资源的 URL 未知时有用

皮特:

PUT 用于将状态转移到使用的服务器,当资源的 URL 已知时

更长的答案:

要了解它,我们需要质疑为什么PUT是必要的,什么问题PUT试图解决POST不能。

从REST架构的角度来看,这并不重要,我们也可能没有PUT,但从客户开发者的角度来看,它使他的生活更简单。

在PUT之前,客户无法直接知道服务器所产生的URL,或者如果它全部产生的URL,或者是否要发送到服务器的数据已经更新了,PUT缓解了所有这些头痛的开发者。