Been having similar case with dev teams who have coded every error to be 500. User typed the wrong URL? 500. User tried to access a page without logging in? 500... Makes detecting real errors a pain
this post was submitted on 14 Sep 2025
817 points (99.4% liked)
Programmer Humor
26373 readers
1624 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 2 years ago
MODERATORS
I'd easily take that over '200 for everything'. If at least errors are distinct from success, I'd take that as a win. My standards have been lowered by so many '200 for everything' backends..
And on the other side of this are JS devs that check for neither error response codes or error messages, and write an error into their own data as if it's the result they were after.
Always fun to see GET /orders/{error : "invalid branchID provided"} in your logs.
Makes all issues their problem. Clearly it's not a 4xx error so not something the client did wrong.
load more comments
(4 replies)
Fun story close to a decade ago we were attempting to upgrade our batch scheduler called Tidal to version 6x which had a RESTful API.
One of the reasons we dropped the product was because we were getting 200 status codes meanwhile the output was a java dump of an error message.
They were adamant that this was an us problem, no matter how much I tried to explain to them with numerous links explaining to them that if something has a 200 status code that should mean things worked.
They argued that the 200 meant we were hitting the API fine. We would have to write code to read the return for if it was a error or not. I still don't think they understood how stupid they were, even all these years later.
I have had that argument repeatedly with people. People insisting that HTTP error codes are "transport layer" and it's "wrong" for an API to hijack them to report "application level issues".
No, the whole point of "REST" was to map application semantics to HTTP in a way that actually normalizes some things like error handling and expectations around whether an operation could be expected to be idempotent and make the namespace navigable.
At one point my work announced a person who was an external hire to be the 'API genius' to set my company straight. He came from a super reputable well known company so of course he just the smart guy to fix our technical mess. He had sent a message saying that he had reviewed the teams API and concluded they were not restful. I had a glimmer of optimism, that someone recognized as authoritative would call the RPC style HTTP usage that always returned 200 and steer toward sanity, or at least honesty. No, his feedback was that was all fine, but REST does not use JSON, REST uses Protobuf, so they need to change to Protobuf to claim to be REST. Of all the what the hell I could have predicted, that one was not in my book...
To further your point and remembering my asinine discussions with the vendor.
Fine. I accept what they said. Then the return code should be a 5xx code not a 200.
I genuinely wonder if they addressed their fuckups.
Side note their updated desktop client (because of course new version didn't have one so they had to write one fast) was a java client that needed 16gb of ram to run marginally well lol
A real "API Genius" would be complaining that your API doesn't include HATEOAS, even though I've never once seen an API be used in that way, and few of the big tech APIs actually use it even though they call their APIs RESTful.
load more comments
(1 replies)
load more comments
(3 replies)
Please, please, please, PLEASE return error-codes and problem-details.
Here's the RFC: https://www.rfc-editor.org/rfc/rfc9457.html
Nightmares.
load more comments
(12 replies)
{ "ok": false }
{ "ok": false }
wouldn't that be more like
new Promise(() =>{
return { "ok": false };
})
load more comments
(5 replies)
error = true with no description or answer is basically ten years of searching stackoverflow and reddit threads for an answer.
Honestly at this point if it's source available it's almost faster to dig through and find the affected module on source to determine behavior.
Unless of course it's just crazy abstracted, which can be an unintentional form of obfuscation when applied poorly.
Aaagh! Getting some random old person flashbacks.
Kids. I r-remember a day... You won't believe this... I got a 404 error page... It was otherwise a normal 404 page with a normal message on it, but it had a giant ad on it... like "while you're here, how about you buy this stuff"... It was hell... You've got no idea how lucky you kids are with uBlock...
Yep, I’ve got one of these at work now. Technically, 200 can make sense here if you’re using HTTP as RPC transport, as the server relayed the request to its handler and returned the outcome, but damn if it’s not annoying to actually process the response.
I’ve also seen a lot of devs tie themselves into knots trying to map various execution types to the “semantically correct” HTTP code, but the thing is the abstraction of HTTP is not based around RPC and it’s ultimately a pretty weird fit that we’ve somehow come to view as normal.
Then just return a 500 - Server error. Nice and obscure.
The ability to separate "something wrong with what you sent" (4XX) and "something wrong on the server" (5XX) is very valuable in itself.
Yep
- 2xx - it's good
- 3xx - not here cunt
- 4xx - you don fucked up
- 5xx - we fucked up, whatever you do aint changing shit.
The number of times I've gotten 5xx codes for bad requests is annoyingly high.
Fair. But they still fucked up so at least that's on them
I guess it's like a retail worker apologising excessively because of trauma.
1xx - We’re still working on it
And then there's 418
good old 418, always appears when you really want a cup of coffee
Respond to everything as a teapot
Oh no... this brings back memories LOL
view more: next ›