It depends. I've seen bigco use this technique and their reason was that they wanted to separate problems with API and request from actual issue with their servers/platform. So if you get 200 it means they received request successfully but if there is issue with request they'll include error in response with 200. If it's anything else then there is a networking or delivery problem. It's not standard way to handle things but can be useful at times.
If the server got an issue with your request it can return 400 (Bad Request), which means that the server has received it successfully before acknowledging it as a bad one.
Even then, if the server returns 400 (Bad Request) the server can still attach a response body to that, in plain text/plain, application/octet-stream or even application/json, which could contain elaborate information.
This is not true. Counterpoint, responses like 404 or 503 Bad Gateway do not come from the destination server. They do not indicate the intended server received your request.
Hmm are these assumptions valid? Can't a misconfigured load balancer cause a 404? Couldn't a bug in nginx, node or an app server produce a 500 response outside of your control?
I suppose a misconfigured load balancer or nginx instance could return absolutely anything. I think you'd have to be actually maliciously misprogramming it, though, to reach that level of dysfunction!
Same thing, no? If I ask for /api/user/238885 and I get a 404 back, it's because the resource "user" with ID of 238885 doesn't exist. If I ask for /api/banana/wharrgarbl, it's because the resource "banana" with the ID of "wharrgarbl" doesn't exist.
