REST - how a PUT request processes resource identifiers with automatic addition

Question

In accordance with HTTP 1.1. Specification:

If the Request-URI does not indicate an existing resource, and that the URI can be defined as a new resource by the requesting user agent, the source server can create a resource with this URI.

Thus, PUT can be used to create and update. More specifically, if I execute a PUT request, for example.

PUT /users/1 

and this user does not exist, I expect the result of this query will create a user with this ID. However, how will this work if your backend uses an auto-increment key? Would it just ignore it if this is not possible (e.g. auto-increment is 6 and I request 10) and create if possible (e.g. request 7)?

From the snippet I extracted above, it seems to give you this flexibility, just looking for some explanation.

Answer 1

I would suggest that you use POST, not PUT, for the auto-increment key, or do not use the auto-increment key in the resource identifier.

If you use POST, then you would send POST to /users , not to /users/1 . The answer may redirect you to /users/1 or any other identifier.

If you use PUT, you can click the /users/10292829 , where the number is the unique resource key created on the client. This key can be time-generated or it can be a time hash, session identifier, and some other factors to guarantee unique value for your client audience. Then the server can generate its own automatically incremented index, other than 10292829 or whatever.

For more on this, see PUT vs POST in REST

---

Continuation of.,.

If you enable PUT to / users / XXXXXXX for all users, you will receive two unique unique keys that belong to the same resource. (10292829 and 1 can refer to the same user). You will need to decide how to allow each of these different keys to be used in a REST URL. Due to the need to coordinate the use of these two different identifiers, I would prefer to use the first option, POSTING to /users and get the unique unique REST URL of the created resource in the response.

I simply re-read the relevant section of RFC 2616 and saw a return code specially designed for this in REST applications:

10.2.2 201 Created

The request has been completed and a new resource has been created. A newly created resource can be referenced by the URI (s) returned in the response entity, with the most specific URI for the resource specified by the Location header field. The answer SHOULD include an object containing a list of characteristics and locations of resources from which the user or user can select the most suitable one. The entity format is determined by the media type specified in the Content-Type header field. The source server MUST create a resource before returning the 201 status code. If the action cannot be performed immediately, the server MUST respond to a 202 (Accepted) response instead.

So, the RESTful path to go to is POST to /users and return 201 Created , with the Location: header indicating /users/1 .

Answer 2

You should use POST to create resources, while PUT should be used only for updating. In fact, the REST semantics force you to do this.