Well I suppose this is solves a problem with differentiating between malformed payloads and such compared to API-specific errors. But in reality, you're just mu

Well I suppose this is solves a problem with differentiating between malformed payloads and such compared to API-specific errors. But in reality, you're just multiplexing the errors inside the 200 response without standard categorization. HTTP errors are nice because it gives the user immediate direction where to debug their problem. If an API returned 200 with error: 'unavailable to process a request' I'd argue that's way worse than returning 403 with no message at all. Ultimately I think why this is so confusing is because HTTP error codes are confusing and they should be clearly defined and/or include more codes specific to application errors rather than the network. It makes life much easier when you can see immediately the type of error you receive and if I had to depend on my API producer to write sensible error messages using 200 return codes I'd lose my mind.