As a client I generally dislike APIs that use 200 for error conditions. The problem is that API implementors often change the structure of the response.
GET /thing/THG123
# on success:
{"id":"THG123", "name":"thingie"}
# on failure:
{"error":"no such thing"}
Working in typed languages, this requires parsing the response, determining success or failure, then reparsing the response into the appropriate type. Annoying.
Of course it's not always like that, some APIs will put both the error and data in a wrapper object and one field or the other will always be null:
This is less annoying but it's still tedious. We could eliminate the wrapper if we only had an out-of-band signal to indicate whether the client should expect a success response or an error response... like maybe an HTTP status code? I mean, it's right there, why not use it?
Of course it's not always like that, some APIs will put both the error and data in a wrapper object and one field or the other will always be null:
This is less annoying but it's still tedious. We could eliminate the wrapper if we only had an out-of-band signal to indicate whether the client should expect a success response or an error response... like maybe an HTTP status code? I mean, it's right there, why not use it?