Congratulations! You failed.
this post was submitted on 14 Sep 2025
823 points (99.4% liked)
Programmer Humor
26390 readers
1337 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
GraphQL makes this same mistake
That’s true, but for a good reason. GraphQL is transport agnostic, so using HTTP status to represent errors doesn’t make sense. HTTP is just a carrier for GraphQL, and the status code represents whether or not the HTTP part was successful.
If only that were true. They are intimately connected and to pretend otherwise is laughable to me
load more comments
(3 replies)
Well no, the HTTP error codes are about the entire request, not just whether or not the actual header part was received and processed right.
Like HTTP 403, HTTP only has a basic form of authentication built in, anything else needs the server to handle it externally (e.g. via session cookies). It wouldn't make sense to send "HTTP 200" in response to trying to access a resource without being logged in just because the request was well formed.
Many GraphQL and gRPC APIs do exactly that and return HTTP 200 even if the request didn’t auth.
Just because you are heavily biased toward using HTTP status for application layer errors doesn’t make it right. It is so wildly common that people can’t imagine it working another way, and I get that.
But it’s not “wrong” to do application layer auth status codes and apply no transport layer auth status codes It’s just a different paradigm than most devs are used to.
Ehh, that really feel like "But other people do it wrong too" to me, half the 4xx error codes are application layer errors for example (404 ain't a transport layer error, neither is 403, 415, 422 or 451)
It also complicates actually processing the request as you've got to duplicate error handling between "request failed" and "request succeeded but actually failed". My local cinema actually hits that error where their web frontend expects the backend to return errors, but the backend lies and says everything was successful, and then certain things break in the UI.
load more comments
(3 replies)
Think the point would be that it's super easy to also set a 'non-ok' status in HTTP. Sure it may be insufficient for sophisticated handling, but at least you can get a vague sense of 'something went wrong'..
Sure have your more specific API specific error code and your error details in the body, but at least toss a generic '500' into the status code. I often find myself writing client software where I don't need specific handling I just need to know 'it failed', and it's obnoxious to deal with these interfaces where I have to sweat multiple potential ways for it to report failures when I just don't care about the specifics. Sometimes an API doesn't even have a consistent place that it sticks it's return code, some don't even define a reasonable way to know 'failure' and require you to explicitly map a huge number of 'info' to ascertain if it's normal or error type state.
load more comments
(1 replies)
Another favorite is when the API barfs a stacktrace instead of valid JSON.
Every time I see someone recommend this at work I die a little inside. Like… C’mon!
Marketo my ~~beloved~~ the bane of my existence. Actually without a doubt the worst API I've ever worked with in my career. The response schemas are random and a 200 means nothing because it might also include a "success": "false"". Our backend API is Python and we have strict typing rule but Marketo really makes that difficult
Either way, the webpage didn’t load. And fuck literally everyone involved for not explaining to me what I need to do to fix it.