With REST you have POST to create a record and GET to retrieve one. GET often uses the ID created by POST to access a record, e.g. [ServerAddress]/order/[ID]. The same also goes for updating a record. So ID is THE key element to access an element (unless
you subscribe to HATEOAS). Hence, it would make sense to me that the response to a POST includes the ID. However, I wonder if this can be in conflict with HTTP specs. Here is chapter
10.2.2. 201 Created I am also copying the text below. It says that the record/resource
can(!) be referenced by the URI(s) returned with the most specific URI in the Location header. So you could return the URL for the GET command but then if you want the ID you have to extract it from that URL. You could also return an URN like
urn:uuid:[ID] but I haven't really seen anybody doing that and again you would have to extract the ID. Now it says "can" and not MUST so these URI(s) seem optional. On the other hand, it says "The response SHOULD include an entity containing
a list of resource characteristics and location(s) from which the user or user agent can choose the one most appropriate." Note the SHOULD which is stronger than the "can" regarding the URI. So would this be the place to put the ID, i.e. into
a JSON object? If that is the place to put it, then does it still make sense to also define the above mentioned URI(s) as that would duplicate information?
10.2.2 201 Created
The request has been fulfilled and resulted in a new resource being created. The newly created resource can be referenced by the URI(s) returned in the entity of the response, with the most specific URI for the resource given by a Location header field.
The response SHOULD include an entity containing a list of resource characteristics and location(s) from which the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content-Type header field.
The origin server MUST create the resource before returning the 201 status code. If the action cannot be carried out immediately, the server SHOULD respond with 202 (Accepted) response instead. A 201 response MAY contain an ETag response header field
indicating the current value of the entity tag for the requested variant just created, see section 14.19.
