this post was submitted on 14 Sep 2025
831 points (99.4% liked)

Programmer Humor

26686 readers
2424 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

founded 2 years ago
MODERATORS
 
top 50 comments
sorted by: hot top controversial new old
[–] neuracnu@lemmy.blahaj.zone 187 points 2 weeks ago
[–] napkin2020@sh.itjust.works 98 points 2 weeks ago* (last edited 2 weeks ago) (3 children)
[–] spizzat2@lemmy.zip 46 points 2 weeks ago* (last edited 2 weeks ago) (1 children)
[–] meekah@gehirneimer.de 22 points 2 weeks ago

wouldn't that be more like

new Promise(() =>{
    return { "ok": false };
})
[–] PoolloverNathan@programming.dev 25 points 2 weeks ago (2 children)
[–] SkaveRat@discuss.tchncs.de 14 points 2 weeks ago
{ "ok": "no" }
[–] InnerScientist@lemmy.world 8 points 2 weeks ago
 { "OK": "Ah ah ah, you didn't say the magic word." }
[–] cupcakezealot@piefed.blahaj.zone 64 points 2 weeks ago (2 children)

error = true with no description or answer is basically ten years of searching stackoverflow and reddit threads for an answer.

[–] wetbeardhairs@lemmy.dbzer0.com 11 points 2 weeks ago (1 children)

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.

load more comments (1 replies)
[–] TomasEkeli@programming.dev 44 points 2 weeks ago (9 children)

Please, please, please, PLEASE return error-codes and problem-details.

Here's the RFC: https://www.rfc-editor.org/rfc/rfc9457.html

[–] darvit@lemmy.darvit.nl 4 points 2 weeks ago (1 children)

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.

[–] TomasEkeli@programming.dev 4 points 2 weeks ago (3 children)

Why even use HTTP, when you can just send bytes directly over the physical network card, right?

Because standards make it better for everyone. You've no idea when, who or in what context the error will happen or be received by.

It takes so little to return ProblemDetails, and improves the experience of devs using your API so much. Just do it. Stop thinking up edge cases and faffing about with excuses. Do it.

load more comments (3 replies)
load more comments (7 replies)
[–] umbraroze@slrpnk.net 36 points 2 weeks ago (1 children)

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

I was going to say that sounds like situation normal by the 2020s… Until you said uBlock.

[–] whoisearth@lemmy.ca 30 points 2 weeks ago (1 children)

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.

[–] jj4211@lemmy.world 13 points 2 weeks ago (6 children)

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

load more comments (6 replies)
[–] NigelFrobisher@aussie.zone 28 points 2 weeks ago* (last edited 2 weeks ago) (1 children)

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.

[–] TomasEkeli@programming.dev 35 points 2 weeks ago (2 children)

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.

[–] MyNameIsIgglePiggle@sh.itjust.works 44 points 2 weeks ago* (last edited 2 weeks ago) (3 children)

Yep

  • 2xx - it's good
  • 3xx - not here cunt
  • 4xx - you don fucked up
  • 5xx - we fucked up, whatever you do aint changing shit.
[–] mercano@lemmy.world 15 points 2 weeks ago* (last edited 2 weeks ago)

1xx - We’re still working on it

[–] Hawk@lemmy.dbzer0.com 9 points 2 weeks ago (1 children)
load more comments (1 replies)
[–] Ziglin@lemmy.world 6 points 2 weeks ago (1 children)

The number of times I've gotten 5xx codes for bad requests is annoyingly high.

load more comments (1 replies)
load more comments (1 replies)
[–] WhiteRice@lemmy.ml 24 points 2 weeks ago (1 children)

It’s not us, it’s you

[–] lunarul@lemmy.world 23 points 2 weeks ago* (last edited 2 weeks ago)

It's us: 5xx

It's you: 4xx

[–] Slotos@feddit.nl 18 points 2 weeks ago (2 children)

JSON API almost always means “not REST”. In other words, it works as intended.

[–] JackbyDev@programming.dev 7 points 2 weeks ago

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.

[–] Aatube@kbin.melroy.org 6 points 2 weeks ago (11 children)

how would you return metadata or more detailed error codes?

[–] eager_eagle@lemmy.world 5 points 2 weeks ago

returning a 400 never prevented me from adding more info to the response

[–] Slotos@feddit.nl 5 points 2 weeks ago (1 children)

However you like, REST doesn’t dictate anything there. Just be consistent and use hypermedia.

JSON APIs almost never follow REST because they almost never use JSON as hypertext. Worse, no complete stable hypertext JSON standard exists. There’s JSON-HAL, but it lacks a way to represent resource templates (think HTML’s <form>).

Therefore, with JSON APIs ignoring one of the most basic idea behind REST, why would anyone expect them to follow another idea of REST - consistency?

REST is a deceptively simple concept. Any time you build an HTML website a human can navigate without consulting documentation, you’re doing it better than vast majority of swagger documented corporate APIs.

load more comments (1 replies)
load more comments (9 replies)
[–] reboot6675@sopuli.xyz 17 points 2 weeks ago (7 children)

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

[–] Blackmist@feddit.uk 8 points 2 weeks ago

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.

[–] jj4211@lemmy.world 7 points 2 weeks ago

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

load more comments (5 replies)
[–] Cruel@programming.dev 15 points 2 weeks ago (1 children)

Congratulations! You failed.

load more comments (1 replies)
[–] PastelKeystone@lemmy.world 7 points 2 weeks ago

Another favorite is when the API barfs a stacktrace instead of valid JSON.

[–] Olap@lemmy.world 7 points 2 weeks ago (2 children)

GraphQL makes this same mistake

[–] porkloin@lemmy.world 5 points 2 weeks ago (9 children)

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.

[–] Olap@lemmy.world 6 points 2 weeks ago (1 children)

If only that were true. They are intimately connected and to pretend otherwise is laughable to me

[–] porkloin@lemmy.world 7 points 2 weeks ago (2 children)

What do you mean? You can literally run GraphQL without HTTP. This isn’t just a GraphQL-ism, gRPC also does it https://grpc.io/docs/guides/status-codes/

I understand that most people use GraphQL over HTTP and that from a developer perspective you’d rather have HTTP status codes like every other REST API. To which I’d say, why don’t you just use REST instead?

There are a bunch of legitimate reasons why a clean separation of transport layer and application layer makes sense - you just aren’t using them so it feels like an arbitrary frustration to you.

Have you ever run an application like a golang REST API behind an envoy or nginx proxy or load balancer and gotten an HTTP status 500 back and wrongly assumed it was coming from your application/golang code, only to later find it was a problem at the proxy or load balancer? If so, you’ve experienced the misdirection of combining transport and application layer being forced to share a status field. This isn’t a trivial example - time is wasted every day by developers misdiagnosing errors originating from transport as application errors, and vice versa.

You might not like it, but separating them IS smart design.

load more comments (2 replies)
load more comments (8 replies)
load more comments (1 replies)
[–] NotSteve_@piefed.ca 6 points 2 weeks ago* (last edited 2 weeks ago)

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

[–] Subscript5676@lemmy.ca 6 points 2 weeks ago

Every time I see someone recommend this at work I die a little inside. Like… C’mon!

[–] ipkpjersi@lemmy.ml 5 points 2 weeks ago

Oh no... this brings back memories LOL

load more comments
view more: next ›