There's a special place in Hell for people who design APIs that returns 200 but then put error messages in the response body.

Im pretty sure they just throw them in the brewing pots with serial killers

Then you should try Virustotals which gives you empty string when it doesn't like your input or your api key is wrong :v

I can confirm that.

This made me burst out laughing on the bus. My first api had a bunch of stuff like this.

I had a phase when I first learned error handling where I felt that if you could detect an error before it actually occurred and instead abort (or worse, "fix" it by parsing or making assumptions the user didn't ask for), then it was no longer an error. Good job, me. One potential error gone.

I had stuff like 404 on empty search results, 200 with json on error (remember to check the response.error prop!), and generally 204 on anything that "was allowed to be undefined".

I hope I atoned by the hours I spent being confused and misled by my own errors.

There's also a place in Hell for people who return 503 while the service is getting up and in browser it shows valid page, that will automatically reload when service finishes booting (I'm looking at you Jenkins). This unfortunatelly breaks load balancer checks, if boot takes too long.

I don't wanna go to hell!! Is just that is easier to write red.send("error...") than looking up what's the appropriate response code!

at least finally i know where my place is

Well.. graphql does exactly that :\

Does it count if it kinda worked and returned a 200?

Right?? https://devrant.com/rants/719827/...

@benj Go to your room and think about what you just said.

@devios1 😓

How does this make paid dev more fun? 😅 Am I missing something?