Sending HTTP status code 200 with error info in the body

Found this awesome license plate in Oslo today

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: ┻━┻ ︵ヽ(`Д´)ﾉ︵ ┻━┻

RE: Why I punched Dave
In my defense to the accusation against me punching back end developer dave in the face, look at the following response:
HTTP 1.1
status: 200
mesaage: OK
body: {
"success": "false",
"message": "error"
}

Spent most of the day debugging issues with a new release. Logging tool was saying we were getting HTTP 400’s and 500’s from the backend. Couldn’t figure it out.

Eventually found the backend sometimes sends down successful responses but with statusCode 500 for no reason what so ever. Got so annoyed ... but said the 400’s must be us so can’t blame them for everything.

Turns out backend also sometimes does the opposite. Sends down errors with HTTP 200’s. A junior app Dev was apparently so annoyed that backend wouldn’t fix it, that he wrote code to parse the response, if it contained an error, re-wrote the statusCode to 400 and then passed the response up to the next layer. He never documented it before he left.

Saving the best part for last. Backend says their code is fine, it must be one of the other layers (load balancers, proxies etc) managed by one of the other teams in the company ... we didn’t contact any of these teams, no no no, that would require effort. No we’ve just blamed them privately and that’s that.

#successfulRelease

Coworker: "Hey can you look at this site and tell me why its loading so slow?"

*inspects console and sees 10 links for stylesheets and 33 script tags and over 200 total http requests.

wot n tarnation -___-

A programmer once explained Nietzsche like this:
A long time ago, god created the world, but forgot to leave a developer documentation, thus the whole world was like legacy code...
And humans are like the end user of this world, and some among them spent time studying it, using the Moral API, hoping to get a result of "http 200 ok" from our world for the peace of mind. But the true operation of this world is still yet unknown...
As time passes, humans begin to find that in Moral API, good and evil are two base classes, and all the other moral properties (like ethic, justice and stuff) are just other classes based on those two classes through multiple inheritance.
One day, when programmer Nietzsche was observing the world's runtime behavior, he came up with a question:
"Did god really use good and evil as base classes? Could it be that they are actually derived classes?"
Most of the world is currently in the favor of mankind, and god must've wrote individual user cases for it's end users, he thought.
This made Nietzsche thinking: if end users are considered into two cases: the strong and the weak, how would the world be designed base on its user story?
Let's think about the strong, they can bully the weak as they please, and there's nothing the weak can do to stop them. In this case whether the Moral API exists or not doesn't fulfill the need of the strong.
But when it comes to the weak, Nietzsche thinks that because the weak cannot fight the strong, they need to belittle bullying and praise the strong for being nice. When the weak does this, it covers their powerless state to some extent, making them look somehow equal to the strong by being capable of commenting.
God might have coded the Moral API to fit the weak's requirement, also adding some public methods for the weak to comment on the strong. If the strong takes care of the weak, they call him nice and good, if the strong bullies people, they call him bad and evil.
That's when Nietzsche realized, that good and evil are both derived classes from the weak, and the base class should be the strong and the weak.
Then he started a series of studies about the Moral API, and got some thesis that persuaded lots of other end users...

HTTP 200 responses on failures… 😒

GF: hey wanna get pizza for dinner?
BF: HTTP response 200
GF: ... 😐

Senior colleagues insisting on ALWAYS returning HTTP status 200 and sticking any error codes in the contained JSON response instead of using 4×× or 5×× statuses.

Bad input? Failed connections? Missing authorization? Doesn't matter, you get an OK. Wanna know if the request actually succeeded? Fuck you, parse potential kilobytes of JSON to get to the error code!

Am I the asshole or is that defeating the purpose of a status code?!

It fucking staggers me how many backend/devops-y people don't understand what a client side "request timeout" is, versus a server side one.

What does it mean:

The client was fed up with the servers bullshit, and decided to piss off and not wait around for the server to take forever to respond, because life's too short.

How not to solve/debug this issue:

- "I've checked the API request in tool xyz, and it works fine for me"

Congratulations, you've figured out how to call an API once, in isolation to the rest of the application, and without any excessive load. And using a different client to me, with a different configuration. Lets get back to actually looking at the issue shall we?

- "I only see HTTP 200's in the logs"

Yep, you probably will in most circumstances, because its the client complaining about it taking too long, not the server. If the server was telepathetic and knew what the client was thinking/doing at all times, we wouldn't have half of the errors we do.

- "Ah ok, I understand ... so how do I solve this?"

Your asking me? I don't fucking know, I didn't build the server! Put better logging in place and figure out why sometimes it takes forever.

Jesus fucking christ

Did i just get rick rolled through a user agent?

"[17/Nov/2020:10:20:42 +0000] "GET / HTTP/1.1" 200 1274 "-" "We are no strangers to love. You know the rules and so do I. A full commitment is what Im thinking of. You wouldnt get this from any other guy.." "-""

That's actually something that happened fairly recently.. just that I didn't have the energy left at the time to write it down. That, or I got my ass too drunk to properly write anything.. not sure actually.

So on paper I'm unemployed, but I do spend some time still on pretty much voluntary work for HackingVision, along with a handful of other people.

At the time, we were just doing the usual chit-chat in the admin channel, me still sick in my bed (actually that means that I wasn't drunk but really tired for once.. amazing!) and catching up to what happened, but unable to do any useful work in this sick state. So, tablet, typing on glass, right. I didn't have any keyboard attached at the time.

One of the staff members (a wanketeer from India) apparently had an assignment in a few hours for which he needed to write a server application in Java. Now, performance issues aside, I figured.. well I've got quite a bit of experience with servers, as well as some with client-server protocols. So I got thinking.. mail servers, way too overengineered. Web servers.. well that could work, I've done some basic netcat webservers that just sent an HTTP 200 OK and the file, those worked fine.. although super basic of course. And then there's IRC, which I've actually talked to an InspIRCd server through telnet before (which by the way is pretty much the only thing that telnet is still useful for, something that was never its purpose, lol) and realized that that protocol is actually quite easy to develop around. That's why I like it so much over modern chat protocols like XMPP, MQTT and whatnot. So I recommended that he'd write a little IRC server in Java. Or even just a chatbot like I attempted to at the time, considering that that's - with a stretch of course - a sort-of server too.

His fucking response however, so goddamn fucking infuriating. "If the protocol is so easy, then please write me down how to implement it in Java."

Essentially do his fucking work for him. I don't know Java, but as a fucking HackingVision admin, YOU SHOULD FUCKING KNOW THAT HACKERS CAN'T STAND LAZY CUNTS THAT CAN'T EVEN BE ASSED TO GOOGLE SHIT!!! If I wanted to deal with cunts like that, I'd have opened the page inbox with all its Fb h4xx0ring questions, not the fucking admin chat!

And type it on a goddamn fucking piece of glass, while fucking sick?! Get your ass fucked by a bobs and vegana horny fuck from the untouchable caste, because that's where you fucking belong for expecting THAT from me, you fucking bhenchod.

But at least I didn't get my ass enraged like that to say that to him in the admin chat. Although that probably wouldn't have been a bad thing, to get his feet right back on the ground again.

Me: please return http code 202 in your http service.

My collegue: ok.

After one hour...

Me: you are returning 200, I told you 202. Let me see the code:

OMFG she was writing the string "202" in the response body!!!

I do not know how to escape from all of this shit.

"200 Internal Server Error"

Yep, I did that. Because the lousy crapheads I work with were too lazy to handle any other HTTP status so anything else breaks the whole thing. And it's a pain to roll out another release of their part of the backend so "this isn't a priority". Also, they don't feel the need to check the JSON body of the response for the "status":"ok"/"fail" because what could ever go wrong, right? I effectively have no way of conveying to them that there was an error on this end of the API so they show success toast on the frontend irrespective of what really happened.

Just found this HTTP response.

Status Code:
200 - OK

Body:

{
status: "success",
response:
{
status: "error",
}
}

Who the fuck uses http code 200 for a failure. Seriously have you ever heard something about a need to parse the shit you're returning...

Now I don't know whether it's me who's wrong, but man there are more than 80 different codes defined so there really should be something for you, don't you think?

And don't give me shit like "well the request worked so we return 200 it's only that the request wasn't correct". What for a fucking peace of something are you... Those codes are for that exact reason.

Anyways I'm going to parse the shit with string compare and afterwards kill myself out of shame. Whish me luck...

At work today I met an api that redefines http status codes to mean something else. Naturally this makes integrating between systems a whole thing when system a keeps spitting out 207 and system b will not accept anything other than 200. Thanks for nothing. WHY WOULD ANYONE EVER WANT TO DO THAT THO? there's just no good reason to.

Anyway hens how r yous?, hope you're all doing well and that your coffee is as strong and black as the void <3

Any enterprise web service which ignores http standards. If you have a Fucking error return 500 not 200 with an error string you f--k

If an http request can't perform the requested operation, should server send 500 error code? Or 200 with status and status message in response?

Isn't 500 used only for unhandled exceptions on server side?

That moment when returning correct HTTP status codes from an API become a feature request 😒

For the meantime I will need to deal with endpoints returning status 200 for everything, and status 500 when the service crash. 🤦🏼‍♂️

When the HTTP status = 200, but the response body says error 400....

SO MAD. Hands are shaking after dealing with this awful API for too long. I just sent this to a contact at JP Morgan Chase.

-------------------
Hello [X],
1. I'm having absolutely no luck logging in to this account to check the Order Abstraction service settings. I was able to log in once earlier this morning, but ever since I've received this frustratingly vague "We are currently unable to complete your request" error message (attached). I even switched IP's via a VPN, and was able to get as far as entering the below Identification Code until I got the same message. Has this account been blocked? Password incorrect? What's the issue?

2. I've been researching the Order Abstraction API for hours as well, attempting to defuddle this gem of an API call response:

error=1&message=Authentication+failure....processing+stopped

NOWHERE in the documentation (last updated 14 months ago) is there any reference to this^^ error or any sort of standardized error-handling description whatsoever - unless you count the detailed error codes outlined for the Hosted Payment responses, which this Order Abstraction service completely ignores. Finally, the HTTP response status code from the Abstraction API is "200 OK", signaling that everything is fine and dandy, which is incorrect. The error message indicates there should be a 400-level status code response, such as 401 Unauthorized, 403 Forbidden or at least 400 Bad Request.

Frankly, I am extremely frustrated and tired of working with poorly documented, poorly designed and poorly maintained developer services which fail to follow basic methodology standardized decades ago. Error messages should be clear and descriptive, including HTTP status codes and a parseable response - preferably JSON or XML.
-----

This whole piece of garbage is junk. If you're big enough to own a bank, you're big enough to provide useful error messages to the developers kind enough to attempt to work with you.

Hi guys!

I never thought that this day will come, be here is my first rant with a big dose of frustration.

So, I'm working on the API team of one of ower products and a coworker that works on the webapp has a lot of problems (don't want to be mean, but he has problems like 'i can't catch a 404 http status, please send a 200 with a message' ) and he always go and wines about the API and that he can't do his job because the API is faulty...

But it is not the case, every functionality of the API is well tested and it works as it should.

So, tonight I was the only one left from my team and the project manager comes and
starts asking me about why I am returning http status codes with all my responses, how the login works and other stuff like that...

Just wasted more than an hour to prove that all the code that I wrote works as expected...

What the FUCK im fixing integrations on some dumbass's API. Biz wants this in prod on monday. It's fucking saturday. Anyway

Me: why did you give us a 200 even if its an error
Them: thats normal
Me: If it's an error it shouldnt be 200
Them: its a 200 because the api params are correct but differ in value so its not an http error but an api error

lmao

-> Had to remap all api endpoints on the backend...
-> The system architect raised a critical bug, saying he can't delete reports from the GUI even though the back-end is returning HTTP 200 (for now, say we also save some sort of reports in our DB)...
-> While remapping, I had returned get in the delete call xD
-> He thanked me for not doing the other way round, delete function in get call xD

Performing code review for design quality.

So you return HTTP code 200 for 'ok'. So what do you return when things are not 'ok'?

Obviously something that's not 200. Like 300 (The message with the code was literally "not okay").

I am trying to implement an API. It has a very good documentation, everything is written clear and simple, along with

- HTTP 401 on unauthorized request and
- Error codes from 1-35 with definitions

Opened the provided sample file, changed the username, password and client code fields to our own in the source, then tried the request. The Response:

HTTP 200
{"ErrorCode":-1,"ErrorDescription":"Unauthorized."}

Well, thank you very much! 🤬

STOP sending HTTP 200 with the error on the body for crying out loud!!!

I think I've figured out why
http:200 ERROR
Is sometimes returned from some APIs... Sort of legit