[mrweasel]

> As long as they get most of the 400 status codes right (specifically 200, 401, 403, 429)

A client had build an API that would return 200 on broken requests. We pointed it out and asked if maybe it could return 500, to make monitoring easier. Sure thing, next version "Http 200 - 500", they just wrote 500 in the message body, return remained 200.

Some developers just do not understand http.

[marcosdumay]

I just consumed an API where errors were marked with a "success": false field.

The "success" is never true. If it's successful, it's not there. Also, a few endpoints return 500 instead, because of course they do. Oh, and one returns nothing on error and data on success, because, again, of course it does.

Anyway, if you want a clearer symptom that your development stack is shit and has way too much accidental complexity, there isn't any.

[SoftTalker]

This is the real world. You just deal with it (at least I do) because fighting it is more work and at the end of the day the boss wants the project done.

[jghn]

Ive seen this a few times in the past but for a different reason. What would happen in these cases was that internally there’d be some cascade of calls to microservices that all get collected. In the most egregious examples it’s just some proxy call wrapping the “real” response.

So it becomes entirely possible to get a 200 from the thing responding g to you but it may be wrapping an upstream error that gave it a 500.

[Sharlin]

Sometimes I wish HN supported emojis so I could reply with the throw-up one.

[LinXitoW]

I've had frontend devs ask for this, because it was "easier" to handle everything in the same then callback. They wanted me to put ANY error stuff as a payload in the response.

[nyarlathotep_]

{ "statusCode": 200, "error" : "internal server error" }

Nice.