REST - PUT请求如何处理自动递增的资源标识符

Question

根据HTTP 1.1.规格:

如果Request-URI未指向现有资源,并且该URI能够被请求用户代理定义为新资源,则源服务器可以使用该URI创建资源.

换句话说,PUT可用于创建和更新.更具体地说,如果我做一个PUT请求,例如

PUT /users/1

并且该用户不存在,我希望此请求的结果是创建具有此ID的用户.但是,如果您的后端使用自动增量键,这将如何工作？如果它不可行(例如自动增量为6并且我请求10)并且如果可能(例如请求7)创建,那么它是否会简单地忽略它？

从我上面提到的片段看来它似乎给你这种灵活性,只是寻找一些澄清.

Answer 1

我建议您使用POST而不是PUT作为自动增量键,或者不要在资源ID中使用自动增量键.

如果你使用POST,那么你要POST /users而不是/users/1.回复可能会将您重定向到/users/1ID或者ID.

如果使用PUT,则可能PUT到/users/10292829数字是客户端上生成的唯一资源键的位置.此密钥可以是时间生成的,也可以是时间散列,会话ID和其他一些因素,以保证客户端受众的价值唯一性.然后,服务器可以生成自己的自动递增索引,不同于10292829或等等.

有关更多信息,请参阅REST中的PUT与POST

跟进...

在允许PUT到/ users/XXXXXXX的情况下,对于所有用户,您最终会得到两个不同的唯一键,这些键引用相同的资源.(10292829和1可能指的是同一个用户).您需要决定如何在REST样式的URL中允许使用这些不同的键.由于需要协调这两个不同的id的使用,我更喜欢使用第一个选项,POST /users并在响应中获取创建资源的唯一REST URL.

我只是重新阅读了RFC 2616的相关部分,并在REST应用程序中看到了专为此设计的返回代码:

10.2.2 201创建

请求已完成,并导致创建新资源.新创建的资源可以由响应实体中返回的URI引用,其中由Location头字段给出的资源的最具体URI.响应应该包括一个实体,其中包含资源特征和位置的列表,用户或用户代理可以从中选择最合适的资源特征和位置.实体格式由Content-Type头字段中给出的媒体类型指定.原始服务器必须在返回201状态代码之前创建资源.如果无法立即执行操作,服务器应该响应202(已接受)响应.

因此,RESTful方式是POST /users并返回a 201 Created,并Location:指定标头/users/1.