I know an architect who designs APIs this way. Also includes a status code in the response object because why have one status code when you can have two, potentially contradictory, status codes?
I inherited a project where it was essentially impossible to get anything other than 200 OK. Trying to use a private endpoint without logging in? 200 OK unauthorized. Sent gibberish instead of actual request body format? 200 OK bad request. Database connection down? You get the point…
Well, looking at your example, I think a good case can even be made for it.
“s23” doesn’t look like an HTTP status code, so including it can make total sense. After all, there’s plenty of reasons why you could want custom error codes that don’t really align with HTTP codes, and customised error messages are also a sensible use case for that.
Of course duplicating the actual HTTP status code in your body is just silly. And if you use custom error codes, it often still makes sense to use the closest matching HTTP status code in addition to it (so yeah, I agree the 200 in your example doesn’t make a lot of sense). But neither of those preclude good reasons for custom codes.
One reason I can think of for including it is that it may make it easier for the consumer to check the status code if it’s in the JSON. Depending on how many layers of abstraction you have, your app may not have access to the raw HTTP response.
Although, yeah you lose the single source of truth though.
I know an architect who designs APIs this way. Also includes a status code in the response object because why have one status code when you can have two, potentially contradictory, status codes?
I inherited a project where it was essentially impossible to get anything other than 200 OK. Trying to use a private endpoint without logging in? 200 OK unauthorized. Sent gibberish instead of actual request body format? 200 OK bad request. Database connection down? You get the point…
It’s the HTTP version of “great job.”
Lmao do they work at Oracle???
I may have run in your acquaintance work, stuff along the lines of
200 OK{ error_code: s23, error_msg: "An error was encountered when performing the operation" }If you happen to run into him, kindly tackle him in the groin for me.
Thanks!
Well, looking at your example, I think a good case can even be made for it.
“s23” doesn’t look like an HTTP status code, so including it can make total sense. After all, there’s plenty of reasons why you could want custom error codes that don’t really align with HTTP codes, and customised error messages are also a sensible use case for that.
Of course duplicating the actual HTTP status code in your body is just silly. And if you use custom error codes, it often still makes sense to use the closest matching HTTP status code in addition to it (so yeah, I agree the 200 in your example doesn’t make a lot of sense). But neither of those preclude good reasons for custom codes.
Still, 200 should not be returned. If you have your own codes, just return 500 alongside that custom code.
I’ve seen the status code in a JSON response before: https://cloud.google.com/storage/docs/json_api/v1/status-codes#401-unauthorized
One reason I can think of for including it is that it may make it easier for the consumer to check the status code if it’s in the JSON. Depending on how many layers of abstraction you have, your app may not have access to the raw HTTP response.
Although, yeah you lose the single source of truth though.
That sounds like either over-abstraction or bad abstraction then