API Record not found

Question

I build this API that takes in Id if that Id is found It will return the data. But if that Id is not found I return 409. When I test it in postman I see the status as 409 is that correct? is that all I need or should it also return some text in the body?

    [HttpGet]
    public IHttpActionResult Read(string type, string id)
     {
        if (id== null)
        {
           var msg = new HttpResponseMessage(HttpStatusCode.NotFound) { ReasonPhrase = "Unable to Find Id" };
msg.Content= new StringContent($"No entity with {id} was found");
           return ResponseMessage(msg);
        }
     }

*I see the status as 404 is that correct?* yes ... all you need to do is read the docs: *Creates an NotFoundResult that produces a Status404NotFound response.* — Selvin, Mar 12 '20 at 16:39
404 is correct HTTP code for 'not found' most browsers and things will show 'Not found' based on this. it is possible to construct a 'Not Found' result with a specific error message, but there isn't a super-simple built-in method for this, see: https://stackoverflow.com/questions/20139621/how-do-i-return-notfound-ihttpactionresult-with-an-error-message-or-exception — GPW, Mar 12 '20 at 16:41
Incidentally, whilst it's *technically* correct to return a 'NotFound' consider your design, as just a 404 isn't telling me if my *type* is not found, my *id* is not found, or even if I've simply mis-typed the URI (as trying to do a GET to `http://yourapi/dummyroute` will *also* give a 404 as the whole *route* is not found... I prefer these days to return a more defined datatype with a property indicating success or failure. — GPW, Mar 12 '20 at 16:50
BTW you are returning not found and if you are seeing 409 then there is something wrong. — Suraj Singh, Mar 13 '20 at 11:59

Caius Jard · Accepted Answer · 2020-03-12T17:12:45.410

1

You do see a "not found" text:

You don't see anything in the body, because your API doesn't send a body, just a HTTP header

Re your comment, and linking in GPW's advice, return something custom - let errors be errors, and have this foreseeable condition as an "OK but no" response, perhaps:

[HttpGet]
public ActionResult Read(string type, string id)
 {
    if (id == null)
       return Json(new { status= "fail", message= "id parameter is required" });
    else if (type == null)
       return Json(new { status= "fail", message= "type parameter is required" });


    var ent = dbcontext.Entity.FirstOrDefault(e => e.Type == type && e.Id == id);

    if(ent == null)
      return Json(new { status="fail", message= "No entity with that type/id was found" });
    else
      return Json(new { status="ok", entityName= ent.Name });

 }

In one of our apps we do use HTTP errors to alter the behavior of the client - there's a promise chain at the client react app and we use returning an error to halt processing of the chain, parse the error out, then go back to parsing knowing the JSON is a slightly different shape. I'm not convinced it's a great way to do it as it's made the client more complex than it could have been but if you want to do that then sure, look at ways of returning meaningful http errors. Personally (and GPW alludes to it) even debugging, many times I've missed the return code in postman, got a blank response, been misled that something else is wrong than what is actually happening/ got a 404 and thought the back end couldn't find the entity when actually I'd got the URL wrong and was getting a 404 for a different reason etc

edited Mar 12 '20 at 17:12

answered Mar 12 '20 at 16:45

Caius Jard

72,509
5
49
80

You can; but then again you can do anything. GPW gives a sensible advice. I'll make an edit – Caius Jard Mar 12 '20 at 17:00
this is using IHttpActionResult can it return a JSON – Jefferson Mar 12 '20 at 17:10
Sure, look at the end example in https://learn.microsoft.com/en-us/aspnet/web-api/overview/getting-started-with-aspnet-web-api/action-results - method is declared to return an IEnumerable and the response ends up as JSON.. I didn't intend for my code to be a drop in replacement for yours, it was to illustrate a concept that everything should be OK for those forseeable problems like ID is null or not found in the DB – Caius Jard Mar 12 '20 at 17:23
so would i return something like this var msg = new HttpResponseMessage(HttpStatusCode.NotFound) { ReasonPhrase = $"No entity with {id} was found"}; I dont see Fail – Jefferson Mar 12 '20 at 17:28
Er.. no. I'm advocating that you return an OK (because the http request worked out; it arrived and was parsed, and there was an application/logic level problem with the data supplied, and a response was sent correctly), with a body that says "fail" and gives a reason. You're quite determined to return an HTTP error (in itself a fairly low level thing) to communicate a failure of application logic (in itself a fairly high level thing). I'm saying "leave the HTTP errors for situations outside your application's control, and use a good/bad status for errors in the flow of your app logic" – Caius Jard Mar 12 '20 at 17:31

API Record not found

1 Answers1