Me: We should change the http response code to anything but 200 OK in the error response case of our API.
Other dev: No, it's fine.
Me: Why?
Other dev: The client successfully receives an error message.
Me: ┻━┻ ︵ヽ(`Д´)ﾉ︵ ┻━┻

That is not how 200 is supposed to be used T_T

I like your ascii smiley

++ for smiley

The people who send error in status 200 should burn in a 200^hell.
°__°

002, NOT OK

res.body === { success: "false" } // true
res.status === 200 // true

I have to consume a few APIS like this at my job

I’ve had to argue this with other devs before.

In the end “management” got involved and told us it should stay as 200 because the client consumes the API and we can’t possibly make our product better if it impacts the client in any way at all.

@Brolls hence why you version your apis such as /v1/makedumbdumb && /v2/makedumbdumb

@perotti that sadly was not an option either, the client said they didn’t want to have to change endpoints etc.

Basically they had a fucked up power over our company, and anything they said went pretty much.

@Brolls time to ditch the company then lol. This is why robots are no threats, managers will get robots to destroy themselves with paradoxes

@perotti haha. I did end up leaving 👍

My product had to integrate with another internal service that registers machine names. One guy wrote and maintains it.

200 return every fucking time! 🤦‍♀️

I used to have this mindset. I found "actual" errors to be this mysterious bottom-level thing and if you could intercept a division by zero and abort it, it was no longer an error.

Come to think about it, error handling is one of the aspects I enjoy the most about development. It's oddly satisfying when you make what would be a breaking change but that check that you wrote two months ago gotchu and makes it a trivial fix.

@namenlossss

Awesome song !!

@Devnergy @yendenikhil here you go http://cutekaomoji.com/misc/...