Oh no... this brings back memories LOL
this post was submitted on 14 Sep 2025
690 points (99.4% liked)
Programmer Humor
26332 readers
2249 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
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.
Please, please, please, PLEASE return error-codes and problem-details.
Here's the RFC: https://www.rfc-editor.org/rfc/rfc9457.html
Counter argument is that error codes and problem details can be used by attackers to reverse engineer and find exploitable parts of a system.
Within reason anyways
So can a 200 response with an error description
Nightmares.
It's often valid to serve a 200 OK with an error in the application data.
How so?
This looks so over-engineered. Most of the time you only need an error message. Make the message clear enough so that it can be shown to the end user.
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.
1xx - We’re still working on it
And then there's 418
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...
{ "ok": false }
{ "ok": false }
wouldn't that be more like
new Promise(() =>{
return { "ok": false };
})
{ "ok": "false" }
{
"false": "ok"
}
$false=true
{ "ok": "no" }
{ "OK": "Ah ah ah, you didn't say the magic word." }
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.
Or a link to a thread on microsoft answers that 404s
that's the worst due to how microsoft answers redirects work making it impossible to go back to the previous page.
It’s not us, it’s you
It's us: 5xx
It's you: 4xx
JSON API almost always means “not REST”. In other words, it works as intended.
I don't wanna be pedantic but most things we call REST aren't REST. The original definition of REST is what we typically call HATEOAS. So when you say JAON API almost always means not REST you need to qualify that.
load more comments
(11 replies)
view more: next ›