When posting an item is it proper form to do a get on the item rather than try to push the ID back to the result?

user_5853643 0
Viewed 38

I'm using System.Net.Http.HTTPClient and in some sample code from a new Xmanarin project I've got a method that works fine. My question is: is this the generally accepted method of getting an object back to the caller?

 public async Task<bool> AddItemAsync(Item item)
 {
     if (item == null || !IsConnected)
         return false;

     var serializedItem = JsonConvert.SerializeObject(item);

     var response = await client.PostAsync($"api/item", new StringContent(serializedItem, Encoding.UTF8, "application/json"));

     /// dig out the URI and fetch it back to be restful...
     var json = await client.GetStringAsync(response.Headers.Location);
     item= await Task.Run(() => JsonConvert.DeserializeObject<Item>(json));
             
     return response.IsSuccessStatusCode;
  }
webapi post rest c#
1 Answers

TL;DR: Whilst it seems in-efficient, this pattern keeps the client code base very simple and allows for the server to manipulate the resource in other ways after applying business logic/rules.

should you re-get a resource immediately after a PUT/POST?

This is not limited to creation events, the first point addresses a create request.

  • If there is limited or no server-side processing related to your post, so a call to GET the same resource immediately after the POST will have the exact same content, or you can easily update the changes on the client side then you are only slowing down the user experience by waiting for the same data to come back

    • If the uri to a resource (so the Id/key) can be determined from the response then you may simply be able to parse that value from the Location or other headers in the response and update the resource on the client accordingly.

  • Some APIs will actually return the content of the resource in the response body itself, or will have an option that you can send as a header on the request to include the content as well. If your API is already returning the content in that response, and that response structure matches the one your app requires, then calling an immediate GET again has no value.

As a general client-side pattern, to call a GET immediately after a create or update is less code than trying to inject Ids and datestamps into the object, it means you implicitly support the concept that business logic on the API may have modified your resource (provided an Id in the very least) so is very resilient to evolution on the API itself.

As a general rule create operations happen in-frequently in many application designs so although it is less efficient in terms of bandwidth it is an acceptable cost to keeping the code clean and manageable.

Can you always use response.Headers.Location to identify the resource

Usually with webapi this is a reliable REST standard convention to start with, but keep reading...

in regard to Web API / REST there are many server-side libraries and conventions that CAN be used that will affect the default behaviour from a server point of view, usually they will return a correct Location header in the response to standard CRUD requests

but that doesn't mean that the developer used these built in behaviours, or didn't override them!

Having decided that you do need to refresh the resource, if your API url conventions mean that the Location of response to a POST is always the uri to retrieve that resource, then by all means continue to use the code you have, just be aware that not all APIs, and not all requests are the same.

user_16902170
Related