HTTP Response Status Code for bad data found on the DB

Question

I expect the JSON response returned by one of my Web APIs to contain a minimum set of fields annotated as mandatory by the business.

Which HTTP status code fit better in case some bad data that does not respect the contract is found on the db?

At the moment we're using 500 but we probably need to improve it (also because Varnish put in front of our service translates that 500 into a 503 Service Unavailable).

Example:

{
  "id": "123",
  "message": "500 - Exception during request processing. Cause: subtitles is a required field of class Movie and cannot be empty",
  "_links": {
    "self": {
      "href": "/products/movies/123"
    }
  }
}

Thanks

I would think if it's bad data it should be a 400 bad request right? — mituw16, Aug 19 '16 at 12:14
Checkout these links, they maybe helpful: http://stackoverflow.com/questions/1434315/http-status-code-for-database-is-down and http://stackoverflow.com/questions/3290182/rest-http-status-codes-for-failed-validation-or-invalid-duplicate — Derick Alangi, Aug 19 '16 at 12:14
No the request is correct, it's just the response that is "bad" because same unexpected data has been found on the db — Gabe, Aug 19 '16 at 12:16
@GaSacchi Ah, I didn't realize the response was bad. In that case 500 seems appropriate to me. — mituw16, Aug 19 '16 at 12:18
@d3r1ck the first one is about db being down and the second one about user request validation, not my case. A following request with a different ID will return 200 for me and the validation failed on the data retrieved on the server side, the client request is legit. Thanks anyway — Gabe, Aug 19 '16 at 12:24
I agree with @mituw16, a 500 Internal Server Error seems most appropriate here. But I think a 503 could also be justified, if this triggers a notification internally, so someone will look at it soon and fix the problem. — CBroe, Aug 19 '16 at 12:32
well, `HTTP` shouldn't even care if data is bad.The application must consider this. `StatusCode 500` denotes some exception scenario which isn't true. — Amit Kumar Ghosh, Aug 19 '16 at 13:24

score 2 · Answer 1 · answered Aug 19 '16 at 13:50

2

An 500 Internal Server Error seems to be enough here to be honest as the issue is essentially from the server side and it doesn't reflect any wrong doing from the client side.

answered Aug 19 '16 at 13:50

Swagata Prateek

1,076
7
15

score 1 · Answer 2 · answered Aug 19 '16 at 16:57

400 means BAD request but there is nothing bad with the request so don't use it.

500 means server error as in something unexpected happened - the code imploded, the galaxy crashed. Bad data is not a cause of any of that.

You have a case of bad data so you have a number of approaches at your disposal.

The first question is what do you intend to do with the bad data?

You could delete it in which case you would return a 204 which means the request is fine but there is no data to send back. I would not return a 404 for no data because 404 means endpoint doesn't exist, not data does not exist.
You could move it out of the main db into a temp data while someone fixes it.

Either way you would not return the bad data and the client doesn't care why that data is bad. All the client is concerned with is there any data or not. Why should the client care that your data is missing a field you deem important?

You could take another approach and return the data you have.

Bottom line : decide how you're dealing with the bad data and don't put any kind of responsibility on the client.

HTTP Response Status Code for bad data found on the DB

2 Answers2