> A 400 if you send mangled JSON, but a 200 if the request was valid but does not pass business validation rules.

What about empty required field in JSON? Is it still mangled or it's already BL?

As it's not to do with the http request and the body was able to be parsed, in my book that'd be classified as being at the application level, so results in a 200 status with a JSON response detailing the issue

200 OK {status: "failed", errors: ["field X is required"]}

How you deal with this on the application side, what JSON statuses you have etc is up to you.

It's an client error and it's highly beneficial to make it 400 for monitoring purposes. You want to see your FE or mobile devs deployed a faulty app.

That depends on how you set up and do your monitoring. Not every failure needs to be indicated by an HTTP status code.

For example, on a server I'm working on there are helper functions that generate different types of responses. Responding in certain ways will produce a 200, but will also log a warning or error.

On the client side, you can create request helpers that all requests go through and that can resolve requests appropriately, rendering error messages to the user etc.

The main thing is to have a well defined, consistent approach.

It's easier to do nothing (already available status codes) then to do something, isn't it? Developers are awful at following consistent approach.