none
REST & POST Response RRS feed

  • Question

  • 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.

    • Moved by CoolDadTx Friday, December 7, 2018 8:27 PM ASP.NET related
    Friday, December 7, 2018 3:35 AM

Answers

  • It might be interesting to look at the .NET core source for the "CreatedResult" which is what you would return in this scenario in an ASP.NET Core WebAPI

    CreatedResult.cs

    It looks as though basically, the location URI is mandatory and is inserted into the response as a "Location" header (similar to a 301/302 redirect).

    The value is optional and is defined as an object so is presumably completely up to the developer on if/what to implement there.

    • Marked as answer by hulamula Monday, December 10, 2018 4:34 PM
    Monday, December 10, 2018 8:00 AM

All replies

  • In my experience, it doesn't really matter.

    No matter you specify the parameters in query string (i.e.: the GET way) or in the response body (i.e.: the POST way), as long as you don't specify parameter with the same name, .NET runtime will put the content in corresponding parameter variable. (Much like in ASP.NET, you can use Request.Param["name"] to get value for Request.QueryString["name"] or Request.Form["name"] .

    Friday, December 7, 2018 7:02 AM
  • Please post questions related to REST development in the ASP.NET forums.

    Michael Taylor http://www.michaeltaylorp3.net

    Friday, December 7, 2018 8:26 PM
  • It might be interesting to look at the .NET core source for the "CreatedResult" which is what you would return in this scenario in an ASP.NET Core WebAPI

    CreatedResult.cs

    It looks as though basically, the location URI is mandatory and is inserted into the response as a "Location" header (similar to a 301/302 redirect).

    The value is optional and is defined as an object so is presumably completely up to the developer on if/what to implement there.

    • Marked as answer by hulamula Monday, December 10, 2018 4:34 PM
    Monday, December 10, 2018 8:00 AM