You can put anything in your dialog box
this post was submitted on 22 Mar 2025
753 points (100.0% liked)
Programmer Humor
21875 readers
312 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
HTTP 200
{"status": "success", "payload": "{\"error\": true}"}
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.
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.
load more comments
(2 replies)
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.
Depending on how many layers of abstraction you have, your app may not have access to the raw HTTP response.
That sounds like either over-abstraction or bad abstraction then
load more comments
(1 replies)
And no error message...
I guess that's how it's done. Yeah.
This is always how graphql works :)
Getting only a message with no error indicator isn’t much better either
load more comments
(1 replies)
This became a religious war at my last role.
I had a similar one at a past work too. A test which was asserting a response status 500.
Like, instead of the test asserting the correct error/status code was being returned, it was instead asserting any error would simply getting masked as a 500.
Basically, asserting the code was buggy....
That made me angry a couple of times but I still miss that place sometimes.
At a prior job, our ~~API~~ load balancers would swallow all errors and return an HTTP 200 response with no content. It was because we had one or two clients with shitty integrations that couldn't handle anything but 200. Of course, they brought in enough money that we couldn't ever force them to fix it on their end.
I once worked on a project where the main function would run the entire code in a try-catch block. The catch block did nothing. Just returned 200 OK. Didn't even log the error anywhere. Never seen anything so incredibly frustrating to work on.
load more comments
(4 replies)
Here I am preferring 200, with success boolean / message string...
Iike HTTP errors codes for real fuck up's, if I see 500 somethings fucked in the app, otherwise a standardised json response body seems way easier
What about both? User supplies bad input? HTTP 400 with response body json describing the error in a standard format?
when you are too lazy to ask your request library to not throw exception on non-200 responses.
load more comments
(1 replies)
Several Favicon APIs do this. Even Google's Favicon endpoint does it, because they return a fallback image. It's pretty annoying.
Welcome to graphQL. The REST abstraction few need, but everyone wants for some reason.
My team recently migrated to graphql and they don't even do it right. The graphql layer still makes REST calls and then translates them to a gql format, so not only do we get no time or computing savings, we also get the bullshit errors
load more comments
(2 replies)
load more comments
(2 replies)
Someone GraphQLs
Honestly makes perfect sense.
- Message received and successfully parsed.
- An error occured while processing request. Ideally they would have a message in the response saying what went wrong if it is relevant for the user.
The problem with only reacting with 500 Internal Server Error is that the user will never improve their input data, if they can do something about it. Responding with 404 is just mean as they wont know if the endpoint is not found or the database couldn't find any data. Differentiating the communication from the processing is i.m.o the best way to do it.
That's not what HTTP errors are about, HTTP is a high level application protocol and its errors are supposed to be around access to resources, the underlying QUIC or TCP will handle most lower level networking nuances.
Also, 5xx errors are not about incorrect inputs, that's 4xx.
…HTTP is a high level application protocol and its errors are supposed to be around access to resources…
I’ve had fellow developers fight me on this point, in much the same way as your parent post.
“If you return a 404 for a record not found, how will I know I have the right endpoint?”
You’ll know you have the right endpoint because I advertised it—in Open API, in docs, etc.
“But, if /users/123 returns a 404, does that mean that the endpoint can’t be found or the record can’t be found?”
Doesn’t matter. That resource doesn’t exist. So, act appropriately.
Standardize a response body across your APIs that specifies the cause of the non-2xx response. Have an enum per API/service for causes. Include them in the API doc.
If anyone still doesn't get it, quietly dispose of them at your friend's pig farm.
It's not like you can't return a body with the 404 that specifies that the user itself is not found versus the ending being wrong.
load more comments
(6 replies)
load more comments
(13 replies)
Except of course that http has a myriad of response codes that are more useful than a 200 with an error body. This was a serious mistake of GraphQL imo
What's wrong with graphql over a web socket? Graphql doesn't necessitate http or any other transport method, it can be done via pigeons. Graphql has zero control over how http works when you use graphql over http, it doesn't force implementors to use http at all
load more comments
(4 replies)
I always loved how Sierra took its error message and turned it into an intentionally quitting the game message because every time they closed the game, instead of closing properly it crashed.
I've got better news:
- notice 200 error:true story on our side
- fix it
- fix it better: add detailed description, add message on what needs to be done on client side
Client to mutual users: meh, we see an error, not our problem. Me: screams in swear language
me with gRPC error codes: nil, parameter error, app error -- OK, you fucked up, we fucked up. Edit: forgot NotFound.
I really should read about the various ones that exist at some point, but I've always got bigger fires to put out.
Edit, since it seems unclear, gRPC != HTTP and does not use the same status codes. I meant that I felt like I was using fewer than I should, though I just checked and basically not.
load more comments
(5 replies)
view more: next ›