this post was submitted on 11 Jun 2024
450 points (99.1% liked)

Programmer Humor

22839 readers
170 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
Feyter@programming.dev
anzo@programming.dev
BurningTurtle@programming.dev
pylapp@programming.dev
450
this is what peak web traffic looks like (lemmy.zip)
submitted 10 months ago by Maven@lemmy.zip to c/programmer_humor@programming.dev
27 comments fedilink hide all child comments
 
you are viewing a single comment's thread
view the rest of the comments
[–] palordrolap@kbin.run 129 points 10 months ago (5 children)

Better than a 200 JSON reply containing the 4xx. "Aay it worked!" "oh."

[–] boonhet@lemm.ee 55 points 10 months ago (1 children)

Worked at a company where the previous devs had implemented their own frameworks for front and backend. Obviously 200 was the only possible code.

[–] Dultas@lemmy.world 10 points 10 months ago

Not even 418?! Uncultured swine.

[–] jballs@sh.itjust.works 34 points 10 months ago (3 children)

This legitimately happened to me a few months ago. A vendor API was returning HTTP 200 with the error details embedded in the JSON response. It was a pain in the ass to troubleshoot.

[–] morbidcactus@lemmy.ca 2 points 10 months ago* (last edited 10 months ago)

Yeah, had that happen a few years ago, thankfully there was a consistent status attributes in the response that I could use but still, annoying

[–] Ironfacebuster@lemmy.world 2 points 10 months ago (1 children)

I guess I might be evil but when I made APIs for my projects I do this, since I blindly accept the response then look at the JSON to see if it was accepted or not

Something like

if (body_has(JSON)) do_stuff_with(JSON) // including error handling if the response has an error else error_no_json()

I do this since I feel like JSON errors should be separate from HTTP errors

[–] jballs@sh.itjust.works 4 points 10 months ago (1 children)

The problem I ran into was the response returned a JSON body, but then had an "error" attribute that was returned in it that had the error details. So we were parsing the JSON and loading elements into our database. We were hitting the API passing in a datetime of when the last success job was run, so basically saying "give me everything that's changed since I last called you."

So yeah, eventually we noticed we were missing small chunks of data. It turned out that every time the API errored out, we'd get a valid JSON response that contained the error message, but it didn't have the attributes we were looking for. So didn't load anything, but updated our timestamp to say when our last successful call was.

Huge pain in the ass to troubleshoot, because the missing data was scattered with no distinguiable pattern.

[–] calcopiritus@lemmy.world 2 points 10 months ago (1 children)

Why not respond with the appropriate HTTP Code, and then also put the same code in the json?

[–] jballs@sh.itjust.works 2 points 10 months ago

That would have been fine for me too. I don't own the API, so I can only speak from a consumer perspective in saying: I don't want a HTTP 200 if my request didn't succeed.

[–] magic_lobster_party@kbin.run 25 points 10 months ago

“Task failed successfully”

[–] capnminus@lemmy.world 13 points 10 months ago

what the fuck

[–] fibojoly@sh.itjust.works 8 points 10 months ago (2 children)

I've had this so often... very frustrating.

I like to think the 400 within a 200 is for "look, I managed to reply to you. But there is bad news"

[–] vithigar@lemmy.ca 7 points 10 months ago

You can give a 400 response a body though. It doesn't stop you from replying.

[–] lseif@sopuli.xyz 6 points 10 months ago (1 children)

regardless, its a big red flag for a poorly designed api

[–] fibojoly@sh.itjust.works 3 points 10 months ago

Oh I agree! It was so annoying.