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.
But WHY are you trying to make a case for a bad practice? Don’t enable this kind of bullshit, please.
If there’s an error, don’t say it’s 200 OK. Give me something, a 4xx, or at least a 500. Sure, add all you want to the body, but respect the goddamn headers!
This fucks up so many things - starting right with API specs and documentation, s23 (or any other code this crap spits out) are not a part of the pdf file, which is the ONLY available documentation for this 3rd party service. If it serves any internal purpose, I have no clue, but for me it’s useless.
Log analytics is a mess, and you can forget about auto-generating a client, of course…
This is just a huge red flag for me, if their public interfaces look like this, I dont want to know whats under the hood, and I’m actively lobbying for us to change to another provider.
I’m making a case for custom codes, not for using a 200 status code with it. My reply said the 200 didn’t make sense.
Of course once you use custom codes, the actual HTTP status codes do become less important, because there’s some redundancy there. That’s not an argument to do it wrong, but it is an argument that accurate HTTP status codes are less of a priority. So understandably some people will take shortcuts.
Apparently you find this very frustrating, but in the end it’s just an implementation detail. But it also sounds like you’re more frustrated with the service API as a whole than the fact it uses custom error codes specifically, so I’m just going to leave it at that.
When I used to work at Oracle every so often a customer would call and complain some function was throwing error “ORA-00000 normal successful completion” and they wanted it filing as a bug and for us to fix it.
I was never quite sure how we were supposed to fix stupid.
Ugh this just reminded me that I ran into this exact issue a couple years ago. We were running jobs every hour to ingest data from an API into our data warehouse. Eventually we got reports from users about having gaps in our data. We dug into it for days trying to find a pattern, but couldn’t pinpoint anything. We were just missing random pieces of data, but our jobs never reported any failures.
Eventually we were able to determine the issue. HTTP 200 with “error: true” in the response. Fml
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.
Yea, I don’t really see a scenario where you are both, making http requests (and therefore care about http responses), and also not able to see the response.
If you are using some wrapper client for an API, you wouldn’t be dealing with the response anyway so it being in json isn’t particularly helpful
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.”
Computer version of dude wincing through the pain, tears in eyes, giving you a thumbs up.
https://youtu.be/688z-4SWxOQ
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.
But WHY are you trying to make a case for a bad practice? Don’t enable this kind of bullshit, please.
If there’s an error, don’t say it’s 200 OK. Give me something, a 4xx, or at least a 500. Sure, add all you want to the body, but respect the goddamn headers!
This fucks up so many things - starting right with API specs and documentation, s23 (or any other code this crap spits out) are not a part of the pdf file, which is the ONLY available documentation for this 3rd party service. If it serves any internal purpose, I have no clue, but for me it’s useless.
Log analytics is a mess, and you can forget about auto-generating a client, of course…
This is just a huge red flag for me, if their public interfaces look like this, I dont want to know whats under the hood, and I’m actively lobbying for us to change to another provider.
I’m making a case for custom codes, not for using a 200 status code with it. My reply said the 200 didn’t make sense.
Of course once you use custom codes, the actual HTTP status codes do become less important, because there’s some redundancy there. That’s not an argument to do it wrong, but it is an argument that accurate HTTP status codes are less of a priority. So understandably some people will take shortcuts.
Apparently you find this very frustrating, but in the end it’s just an implementation detail. But it also sounds like you’re more frustrated with the service API as a whole than the fact it uses custom error codes specifically, so I’m just going to leave it at that.
Lmao do they work at Oracle???
When I used to work at Oracle every so often a customer would call and complain some function was throwing error “ORA-00000 normal successful completion” and they wanted it filing as a bug and for us to fix it.
I was never quite sure how we were supposed to fix stupid.
Ugh this just reminded me that I ran into this exact issue a couple years ago. We were running jobs every hour to ingest data from an API into our data warehouse. Eventually we got reports from users about having gaps in our data. We dug into it for days trying to find a pattern, but couldn’t pinpoint anything. We were just missing random pieces of data, but our jobs never reported any failures.
Eventually we were able to determine the issue. HTTP 200 with “error: true” in the response. Fml
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
Yea, I don’t really see a scenario where you are both, making http requests (and therefore care about http responses), and also not able to see the response.
If you are using some wrapper client for an API, you wouldn’t be dealing with the response anyway so it being in json isn’t particularly helpful