current community

your communities

more stack exchange communities

company blog
Stack Exchange Inbox Reputation and Badges
tour help
Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle who care about creating, delivering, and maintaining software responsibly. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top
up vote 0 down vote favorite

Recently I worked with a Restful API server and encountered a problem with handling database error.

The basic approach is every time a SQL exception occurred, the server will return "500" to client and client will have no idea what is wrong inside the server. It's fine for server errors. But sometimes, the errors are created by user input, especially in case of unique constraint violation and invalid reference, and it is required to return a more user friendly error.

What should I do to correctly handle these cases? As I understand parsing SQL message is a big no. My current approach is add 1 more validation layer to check for these constraints. Which will causes validation to run 2 times, 1 at application level and 1 at database level, which is quite inefficient in theory. So are there any better approaches?

share|improve this question
1  
Validations are your friend. They take care of the most important thing In your system. The data and its coherence. – Laiv Oct 26 at 19:19
up vote 0 down vote

For requests which could be understood but not processed by the server the 422 Unprocessable entity error code might be appropriate.

The 422 (Unprocessable Entity) status code means the server understands the content type of the request entity (hence a 415(Unsupported Media Type) status code is inappropriate), and the syntax of the request entity is correct (thus a 400 (Bad Request) status code is inappropriate) but was unable to process the contained instructions. For example, this error condition may occur if an XML request body contains well-formed (i.e., syntactically correct), but semantically erroneous, XML instructions.

For more specific use-cases, such as unique constraint violation, you could go for the more specific error code, 409 Conflict, basically telling the calee the server once again understood the request but it could not be completed due to conflicting information.

share|improve this answer
    
+1. These are the very same codes I use and the very same usage. Just a side note: be careful about what kind of info you gives into the error message. You might be giving too much info about your system. Client does not need to know what the hell is a constraint violation. – Laiv Oct 26 at 19:50
up vote 0 down vote

Which will causes validation to run 2 times, 1 at application level and 1 at database level, which is quite inefficient in theory. So are there any better approaches?

If you want to generate good error messages, and prevent problems caused by unexpected input, you should validate on multiple levels.

If you expect clients to usually give good input, you can do this in stages:

  1. Validate that the input is valid according to your API specification.
    • If this fails: Return for instance 400/415 depending on the error.
  2. Start a transaction and start doing any operations required by the request.
    • If this fails: Do explicit checks on the original input (or values you stored during previous steps) for those errors you have identified as useful to give specific errors for ("There is already a blog post with the slug 'my-summer-holiday'.")
      • If a specific error was identified: Return 409 with description
      • If no specific problem was found: Return 422 without description (or with generic error)
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.