Status code: 200
Content-Type: application/json
Body: {"error": true, "responseCode":400 }

Sending HTTP status code 200 with error info in the body

The GET /users endpoint will return a page of the first 13 users by default.

To request other pages, add |-separated querystring with the limit and offset, as roman numerals enclosed in double quotation marks. Response status is always equal to 200, plus the total count of the resource, or zero when there's an error.

You can include an array of friends of the user in the result by setting the request header "friends" to the base64-encoded value of the single white pixel png.

Other metadata is not included by default in responses, but can be requested by appending ?meta.json to any endpoint, which will return an xml response.

If you want to update the user's profile picture, you can request an OAuth token per fax machine, followed by a pigeon POST capsule containing a filename and a rolled up Polaroid picture. The status code attached to the return postal dove will be the decimal ASCII code for a happy smiley on success, and a sad smiley if any field fails form validation.

-- Every single external REST API I've ever worked with.

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"
}

It's maddening how few people working with the internet don't know anything about the protocols that make it work. Web work, especially, I spend far too much time explaining how status codes, methods, content-types etc work, how they're used and basic fundamental shit about how to do the job of someone building internet applications and consumable services.

The following has played out at more than one company:

App: "Hey api, I need some data"
API: "200 (plain text response message, content-type application/json, 'internal server error')"
App: *blows the fuck up

*msg service team*

Me: "Getting a 200 with a plaintext response containing an internal server exception"
Team: "Yeah, what's the problem?"
Me: "...200 means success, the message suggests 500. Either way, it should be one of the error codes. We use the status code to determine how the application processes the request. What do the logs say?"
Team: "Log says that the user wasn't signed in. Can you not read the response message and make a decision?"
Me: "That status for that is 401. And no, that would require us to know every message you have verbatim, in this case, it doesn't even deserialize and causes an exception because it's not actually json."
Team: "Why 401?"
Me: "It's the code for unauthorized. It tells us to redirect the user to the sign in experience"
Team: "We can't authorize until the user signs in"
Me: *angermatopoeia* "Just, trust me. If a user isn't logged in, return 401, if they don't have permissions you send 403"
Team: *googles SO* "Internet says we can use 500"
Me: "That's server error, it says something blew up with an unhandled exception on your end. You've already established it was an auth issue in the logs."
Team: "But there's an error, why doesn't that work?"
Me: "It's generic. It's like me messaging you and saying, "your service is broken". It doesn't give us any insight into what went wrong or *how* we should attempt to troubleshoot the error or where it occurred. You already know what's wrong, so just tell me with the status code."
Team: "But it's ok, right, 500? It's an error?"
Me: "It puts all the troubleshooting responsibility on your consumer to investigate the error at every level. A precise error code could potentially prevent us from bothering you at all."
Team: "How so?"
Me: "Send 401, we know that it's a login issue, 403, something is wrong with the request, 404 we're hitting an endpoint that doesn't exist, 503 we know that the service can't be reached for some reason, 504 means the service exists, but timed out at the gateway or service. In the worst case we're able to triage who needs to be involved to solve the issue, make sense?"
Team: "Oh, sounds cool, so how do we do that?"
Me: "That's down to your technology, your team will need to implement it. Most frameworks handle it out of the box for many cases."
Team: "Ah, ok. We'll send a 500, that sound easiest"
Me: *..l.. -__- ..l..* "Ok, let's get into the other 5 problems with this situation..."

Moral of the story: If this is you: learn the protocol you're utilizing, provide metadata, and stop treating your customers like shit.

Rant! I found a bug in payment provider's api. The bug involves sending an invalid (!) Stripe ID to that API, (which I send on purpose btw) Which causes a complete white page when you login to their systems and view the details of that customer. Btw the API will accept that invalid Stripe ID without questioning and returns a 200 status code back.

So I send a mail to there support saying "look I found this bug by accident, this is how you can reproduce it"

And the support team send me a message back saying "then don't send an invalid Stripe ID"...

You don't freaking say... *sigh*

Request URL: /api/v1/user/53b49b5a30
Request Method: GET

Expected Response:
Status Code: 404 Not Found (as the user is actually not present in the DB)

Actual Response:
Status Code: 200 Ok
Response Content:
{
"status": "ERROR",
"errorCode": "404",
"errorMsg": "User Not Found. Please provide a valid user ID",
"type": "Error",
"userMsg": "User Not Found. Please provide a valid user ID"
}

#extremefacepalm

I AM GOING TO PERSONALLY MURDER WHICHEVER SHITBRAINED INCOMPETENT MONKEY THOUGHT IT'D BE A GOOD IDEA TO RESPOND TO ANY AND ALL API ERRORS BY SENDING A RESPONSE WITH THE STATUS CODE 200 AND A BODY OF THE FUCKING STRING "error" AND NOTHING ELSE

WHY?!!?!?!??!

Web api response with a 200 status code

{
error: ".......",
errorCode: "..."
}

Grinds my gears

Most irritating thing I have to deal with when working on a project with a third-party:

{
status: 200,
message: "error"
}

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?!

Summary: Burnout, and everything's broken.

I don't feel like doing a damn thing today. I look at the code and cringe. I look at Slack and think "ugh. i can't." Mental capitals are even too much work.

(I've started reading "Zen and the Art of Motorcycle Maintenance" to try and combat burnout. I'll write a rant/story about it here if I find it helpful. but all I want to do today is drink tea and read.)

But onto the story:

Heroku is deprecating support for and will automatically upgrade any old verisons of Postgres running on its platform after August something (like five days from now).

I performed the upgrade to PG10 on Sunday (and late into the night), provisioning a new follower, blah blah blah.

However, the version of Rails we're using (4.2.x) doesn't support PG10 sequences, so I manually added in support via a monkeypatch. I did this on our QA servers first, obviously, and everything worked as expected. After half a day of no issues, I did the same on production, and again: everything worked as expected.

But today? I keep hearing about new things that are broken. One specific type of alert doesn't work for one specific person (wat). Can't send [redacted] at all. Can't update merchants! Yet there are magically no errors logged.

That last one (well, two) are just great; let me explain: when there's an error concerning merchants, the error gets caught, isn't logged or recorded anywhere so it just disappears, and the rescue block triggers a json response instead and happily exits. This is for an internal admin tool, so returning a user-friendly error is kinda stupid anyway, but masking what actually happened? fuck that dev with an obelisk made from spikes and solidified pain. That json response is also lovely: it's a 200 OK returning {status: 1, data: "[generic message containing incorrect IT jargon]"}. Doesn't even say "error" anywhere. Bloody everything about this pattern is absolutely wrong. Even the friggin' text.

Fucking hell. I want to pipe the entire codebase into shred and walk out the door.

But I digress. So many things are broken, my motivation is wanning to a sliver, and I have a conference call today where I'll undoubtedly be asked why everything is on smoking and/or on fire, and my huge and overly productive week last week will ofc mean nothing by contrast.

Ugh.

`shred ~/dev/work -zfu -n 32 &; ./brew tea --hot && wine ~/takeabreak.exe`

Spend 5 hours debugging why my curl request in PHP was giving 302 status code, and why my postman was giving 200 for the same request.
Then after crying a lot, I realized the URL was wrong in PHP.
*I totally want to smack my head on the wall*

Status: 200
Res.body: errMsg: err is undefined

That's real helpful mongo

Twitch returning errors with 200 status code

WHY
ARE
YOU
WRITING
CODE

"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",
}
}

Have to use a 3rd party API which responds to all requests like

{
status: 200,
data:{
status: 'fail' / 'pass',
data: { data}
}

Should I be sad?

P.S. They ask for a 'userName'

What's a bigger sin.

Returning a status code of 200 and then the message body saying "An Error Occurred"

or

Only performing data validation on the frontend.

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

That sweet feeling when you get response status 200 and everything works just fine 😍😍😏

First company:

- being sat at an office that didn't have chairs with proper back support. It would kill my back every day. Like sitting on a bar stool coding.
- not having access to basic resources (cafeteria, salary bonuses)
- being seriously underpaid ($200 under)
- not having an IT process pipeline (yeah, this is a huge one): no JIRA, no git, no VCS, no continuous integration, etc. I fucking spend 45% of the time fixing coding-unrelated shit.

Second company (very aggravating):

- dumb frontend bitch and privileged colleague who both kept telling me months on end to shut up and who wouldn't listen to my advice on anything, while my advice would actually help the company advance in productive ways. The key here is being told to shut up while stagnating. i.e. dead end job.
- people advancing in the company based on nepotism and favoritism, based on having tits and ass, rather than skills and independence.

- pointlessssssssss meetings where decisions are made solely based on the opinion of Mr. favorite senior dev. The rest just sits there like a bunch of sad saps and yay-nodders. Incompetent PO's who "would like to hear your input" but then when you give it, they completely dismiss you.

- pointlessssssssss monthly meetings with stakeholders, where the dev teams do nothing but clash and act like pussies in front of the PM just to get in his favor, but behind scenes continue to make the same mistakes and telling the CEO everything is fine. Goodness, how can it get more unproductive.

- completely antisocial and nepotistic 'colleagues' who won't even talk to you, let alone smile at you or be friendly. You saying good morning and them pretending you're vapor that doesn't exist. Go go company atmosphere! Especially during lunch, those are the worst times. Imagine sitting at lunch where everyone looks like you killed their dog and the rest is huddled up in little high school groups.
What else? The incessant and pointless smalltalk that makes me want to bang my head against the wall. Talking about dogs, kids, what show was on tv last night. The fuck man, do you have a brain?!

Third company:

- HR bitches who think they are the shit and developers are antisocial, helpless misfits, but they work with computers and they don't even fucking know what a status bar is! The irony!

- forced socializing and stigmatization for the opposite. Imagine coming into a company and you don't say good morning. Should that be a problem? No. Instead, everyone starts dogging on you and hating you just because you didn't smile in their faces and said: hiiiiiiiiiiii how did you sleep? Did you feed your dog? Fuck you.
Elliot (Mr. Robot): "Wouldn't it be awesome if there was a mute button for life?" -boop, boop, boop, boop...- Ahh.. there.. that's much better."

- CEO's sucking up to you but when it comes to salary increase, they say shit like: "Ahhh ya know, it's kinda difficult." Yet another dead end job.

Doing a full rewrite from some DIY spaghetti framework: when it can't find a search query it returns "false" with the status code 200, the same php file responsible for querying an external api is put into all sorts of named folders, so e.g. a user that is in the results page X can continue searching on the same URL, instead of doing proper url rewrites or ajax calls to the one in the root directory, html is thrown into every other php line, a DIY sort function for a numbers array that fails to sort 0 before 1 and that all is just a 10 minute review, can't wait to see the rest.

So one of my clients had a different company do a penetrationtest on one of my older projects.

So before hand I checked the old project and upgraded a few things on the server. And I thought to myself lets leave something open and see if they will find it.

So I left jquery 1.11.3 in it with a known xss vulnerability in it. Even chrome gives a warning about this issue if you open the audit tab.

Well first round they found that the site was not using a csrf token. And yeah when I build it 8 years ago to my knowledge that was not really a thing yet.

And who is going to make a fake version of this questionair with 200 questions about their farm and then send it to our server again. That's not going to help any hacker because everything that is entered gets checked on the farm again by an inspector. But well csrf is indeed considered the norm so I took an hour out of my day to build one. Because all the ones I found where to complicated for my taste. And added a little extra love by banning any ip that fails the csrf check.

Submitted the new version and asked if I could get a report on what they checked on. Now today few weeks later after hearing nothing yet. I send my client an email asking for the status.

I get a reaction. Everything is perfect now, good job!

In Dutch they said "goed gedaan" but that's like what I say to my puppy when he pisses outside and not in the house. But that might just be me. Not knowing what to do with remarks like that. I'm doing what I'm getting paid for. Saying, good job, your so great, keep up the good work. Are not things I need to hear. It's my job to do it right. I think it feels a bit like somebody clapping for you because you can walk. I'm getting off topic xD

But the xss vulnerability is still there unnoticed, and I still have no report on what they checked. So I have like zero trust in this penetration test.

And after the first round I already mentioned to the security guy in my clients company and my daily contact that they missed things. But they do not seem to care.

Another thing to check of their to do list and reducing their workload. Who cares if it's done well it's no longer their responsibility.

2018 disclaimer: if you can't walk not trying to offend you and I would applaud for you if you could suddenly walk again.

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

Right now I'm implementing forwarding in our application.

Everybody in my team has the opinion, that if you open a not existing url you should be forwarded to the dashboard with response Status 200... 404 with error page would be too confusing for the users... 😩

This just happened to me.

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. 🤦🏼‍♂️

I worked for this Chinese company, one of their systems that was supposedly handling millions of US$ in transactions per day had an API that returned HTML tables...

I stop you right there commenter, there was no format=json parameter.

Another of their API I gave up on:

Status = 200
Content = "error"

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

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.

So I'm working on a project that relies on Google apis specifically Maps. What I just found out blew my mind. The company that writes documents about how you should return correct status codes doesn't return correct status codes. If I send a request with a proper API key, I get a 200 okay back. If I send a request with an invalid API key, I also get it 200 okay back

I think UPS' Api documentation and service must be the worst documented and build API I have ever seen from a corporate.

1. The developer website is a mess. A total mess. You can barely find the API type you are looking for.

2. When you get the API and download the documentation, the files, .pdf etc is still a mess. Pages long that most are craps.

3. Each request returns Status Code 200. Even if it is an error. This blew my mind.

4. Each request, based on error type or based on tracking activity returns different JSON schema.

For example, the JSON Schema for a shipment in transit is different from JSON schema for a shipment that has been delivered. A shipment that has been returned, a shipment that required signature etc. They are different from each other.

5. And the worst. They do not provide with test tracking codes. I have found some on internet, but they do not work in development and production environment.

People build apps and only use status 200 and 302

A new development rule I've started to implement:

All backend APIs will be written with the assumption that it's gonna get distributed as an API for 3rd parties to be integrated in their systems - meaning that every API I write will have proper response status codes for appropriate scenarios (like 400, 429, 500 status codes).

No more `res.json({status: false, message: 'message'})` with 200 status code across the board.

Estimates.. First, part of the team makes "high-level" estimates which are based on informal, incomplete, still-evolving specs and an unstable back-end. The project people report the estimates to the client and elevate the status of these inaccurate estimates to that of commitments.

Then, before the "sprint", we review our initial estimates *ahum commitments* in greater (technical) detail. Because there are still a lot of unknowns, we tend to estimate more buffer here (back-end is often not ready, always ping-pong between project people and dev-team about unclear specs, more work than originally expected, and often late modifications to the original spec).

When an estimate becomes more than 50% extra time at the "refinement", we are told: "sorry, we gotta do it in less" and when it doesn't work out, we're kindly asked to spend part of our weekend catching up at 100% pay rate (legally it's 150-200%).

FUCK THIS SHIT

*quotes used abundantly because these terms belong to "agile/scrum" terminology but we're only pretending

Why can no-one, not one single solitary fucker, on StackOverflow get it through their thick skull that when I call PHP's http_response_code() or try to get $_SERVER["REDIRECT_STATUS"], I want the response code from Nginx? No, not Apache. No, I don't want to pass a status code FROM PHP TO NGINX, I want the response code. FROM Nginx. TO PHP.

In what fucking universe does PHP know more about the response code than Nginx? It doesn't. Nginx knows the response code, because that's the fucker that redirected to the error page. I want the error. Passed to the page. From Nginx. To PHP.

NO, http_response_code() DOES NOT MAGICALLY FUCKING WORK, IT RETURNS 200 BY DEFAUL- fuck it.

I was programming a nodejs app using an api written by two other devs in my company. I tried catching the cases where the requests fail, but it just did not work. Then i found out what the reason was: Apparently the other devs thought, it is enough to send the appropriate status in the json body and did not set it in the headers, so I always got a 200 back even if it failed and there was no usable data in the body.