1

I am writing Web-API methods. One such method is similar to

public IHttpActionResult Post([FromBody]MyDTO)
{
   //validations 

   try
   {
      InsertInToDB(MyDTO.SomeField);
   }
   catch(Exception ex)
   {
      // Say some exception has occurred while inserting in to DB. For eg. SomeField is not a acceptable value.
      // What is the response that I should send to the API user ?
      // Notfound, BadRequest does not seem to be fit in this case.
   }

}

Note: InsertIntoDB returns a void

Now, if some exceptions occur within that method what should be the HttpStatusCode that I should send to the user ?

NotFound or Badrequest responses doesn't seem to fit this case. Any ideas ?

1 Answers1

5

The Exception you send back depends on a few things.

First, did the user send you bad information? Or did your server screw up?

4XX status codes are for when the user screwed up.

4XX:

If the problem is the user sent a badly formatted request, return 400 Bad Request.

If the problem is you're using POST to determine if a resource exists (say through search), then a 404 Not Found would be appropriate if a resource they were trying to access wasn't found.

If the problem is that Inserting this value will cause a problem with an existing value (say they have the exact same name and they shouldn't; or some other validation-esque error: 409 Conflict is appropriate.

5XX

5XX status codes are for when your code screwed up. The user did everything right, but you still messed up.

For instance, if your database is down, a 500 or 503 is appropriate.

As an aside, Catching a blanket Exception is bad. In this case, if you have different validations, you should create exception classes that can be thrown if there is a Validation error; to differentiate it from the user doing everything write but the code going wrong.

In this case, I'd have:

ValidationFailedException -> Web tier Returns 400 ConflictException -> Web Tier returns 409 ItemDoesNotExistException -> Web Tier returns 404

Note that your data layer can should not have a dependency on the web tier or anything internet related. That means that you should have internal Exception classes; throw those, and use those to generate the appropriate HttpException in your Web Tier.

Community
  • 1
  • 1
George Stocker
  • 57,289
  • 29
  • 176
  • 237
  • The problem is `someField` is not a valid name to be accepted by the DB. So, in this case, what exception should I use ? I cannot choose `Conflict` too :( – now he who must not be named. Jul 10 '14 at 10:48
  • 1
    If the user screwed up by entering a value they shouldn't have, it's a bad request(400). I've edited my answer to provide more detail. As far as which exception you should use, you should create your own for the data layer, and then in the web tier handle those exceptions to throw web related exceptions (Like `Bad Request`). – George Stocker Jul 10 '14 at 10:51
  • Thanks George. Great explanation. But just one more question: `What if the invoked Stored Procedure in the DB does not exist`? In this case, my DB layer would give me a `SQL exception` and what response-code that I should throw now ?? – now he who must not be named. Jul 10 '14 at 10:54
  • 1
    Umm. Why would the invoked stored procedure not exist? You're not letting your users type in their own stored procedure names to run, are you? If you are, we've got deeper problems. There should *never* be a case where a user knows they're executing a stored procedure, nor should they care. If your code is wrong, take 10 seconds right now and fix it. Rebuild, redeploy. You'll have to go into more detail (in your question) about this specific use case; but from what you've told me, we've got bigger problems. – George Stocker Jul 10 '14 at 10:58
  • Thanks George. I will go back a moment and review whats exactly I am doing and come back. Thanks for the insight – now he who must not be named. Jul 10 '14 at 11:00