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.
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.