根据HTTP 1.1。规格：
如果Request-URI未指向现有资源，那么 URI能够被请求定义为新资源 用户代理，源服务器可以使用该URI创建资源。
换句话说，PUT可用于创建＆amp;更新。更具体地说，如果我做了PUT请求，例如
PUT /users/1
并且该用户不存在，我希望此请求的结果是创建具有此ID的用户。但是，如果您的后端使用自动增量键，这将如何工作？如果它不可行（例如，自动增量为6，我请求10），那么它是否会简单地忽略它？如果可能的话（例如请求7）？
从上面提到的代码片段中，它似乎确实为您提供了这种灵活性，只是寻求一些澄清。
答案 0 :(得分：10)
我建议你使用POST而不是PUT作为自动增量键，或者不要在资源ID中使用自动增量键。
如果您使用POST，则会发送到/users而不是/users/1。回复可能会将您重定向到/users/1或任何ID。
如果您使用PUT，那么您可能会将PUT转到/users/10292829，其中该号码是客户端上生成的唯一资源密钥。此密钥可以是时间生成的，也可以是时间散列，会话ID和其他一些因素，以保证客户端受众的价值唯一性。然后，服务器可以生成自己的自动递增索引，不同于10292829或其他。
有关详情，请参阅PUT vs POST in REST
跟进。 。
在允许PUT到/ users / XXXXXXX的情况下，对于所有用户，您最终会得到两个不同的唯一键，这些键引用相同的资源。 （10292829和1可能指的是同一个用户）。您需要决定如何在REST样式的URL中允许使用这些不同的键。由于需要协调这两个不同的id的使用，我宁愿使用第一个选项，POST /users并在响应中获取创建资源的唯一REST URL。
我刚刚重新阅读the relevant section of RFC 2616，并在REST应用程序中看到了专为此设计的返回代码：
10.2.2 201创建
请求已完成，并导致创建新资源。新创建的资源可以由响应实体中返回的URI引用，其中由Location头字段给出的资源的最具体URI。响应应该包括一个实体，其中包含资源特征和位置的列表，用户或用户代理可以从中选择最合适的资源特征和位置。实体格式由Content-Type头字段中给出的媒体类型指定。原始服务器必须在返回201状态代码之前创建资源。如果无法立即执行操作，服务器应该响应202（已接受）响应。
因此，RESTful方式是POST到/users并返回201 Created，Location:标头指定/users/1。
答案 1 :(得分：0)
您应该使用POST来创建资源，而PUT只应用于更新。实际上，REST语义迫使你这样做。