IMO it does not matter much. You'll write some middleware around API anyway. Handling HTTP codes or handling JSON fields - the only thing that I wish is consist

IMO it does not matter much. You'll write some middleware around API anyway. Handling HTTP codes or handling JSON fields - the only thing that I wish is consistency, so I can handle it all in one place. But what does matter is expectations. People naturally consume lots of HTTP APIs everywhere. And making things like everyone else's doing is important. Everyone's using HTTP codes for their API. That's reality. So I think that it's better to stick to this format until we'll go some circle and get back to SOAP 3.0 or something. If you would ask me, I'd prefer distinct set of statuses for APIs. So nginx will never return it, no matter what (mis)configuration happened. Right now if I misconfigure my reverse proxy, it'll return 404 for everything. This should be gateway error, but it's not and some clients will happily work thinking that everything not found which is not true. So something like 1200/1404/whatever for APIs and 200/404 for other things. And author's approach will not help, because it's equally easy to misconfigure nginx to return 200 with some garbage SPA HTML for every request. Well, at least there's hope that failing to parse it as JSON will signal to client that something's not quite right.