0

Which HTTP status code shall I return, in my API, in case of non-critical server errors?

For example, SomeMethod is called, but fails, because of null passing, or maybe some errors while trying to access database, whatever.

I thought about 500 code, but it's used when server doesn't work at all, while SomeMethod works only if everything is correct.

Of course, body of response contains errors and their descriptions.

Catalyst
  • 1,018
  • 2
  • 12
  • 19
Yurii N.
  • 5,455
  • 12
  • 42
  • 66

2 Answers2

1

Since there's not a specific HTTP code for a "non-critical error", then all I can do is just tell you my opinion, which is - just use 200 and print an exception-like response.

As you said in your comment - you are able to handle the internal error gracefully, so just throw an exception to the client that explains why his request failed (the "why" can be something like "internal database error").

Catalyst
  • 1,018
  • 2
  • 12
  • 19
  • Ok, how about client's expectations, that **200** is always good? Or it's just a documentation problem? – Yurii N. Jul 15 '17 at 15:01
  • @YuriyN., I can give you an example from my workplace, which develops API. We throw an exception in case of such errors, and we send it with 200, and it is perfectly fine. :) – Catalyst Jul 15 '17 at 15:05
  • Seems you're right, no ways other than returning special list of errors. – Yurii N. Jul 16 '17 at 14:40
1

If these "non-critical errors" are caused by a wrong input from the client (e.g., wrong data type), then you should use the client error status code 400 (Bad request).

Here is its description from the standard:

The 400 (Bad Request) status code indicates that the server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing).

Community
  • 1
  • 1
Hamza ED-DOUIBI
  • 33
  • 5