Strictly speaking JSON APIs shouldn’t have HTTP “header” responses of any kind IMO. It’s why you end up with the situation you have here. Header responses are designed for HTTP requests, but JSON is a stand alone format for a response and should not depend or be intermingled with HTTP headers.
As far as standardization of errors I do like using the same codes from HTTP standards but placing them within the JSON result. Regardless it’s best to follow compatible standards such as using JSONapi.org
@danielpclark, I think you are confusing HTTP and HTML. JSON API work on top of HTTP. You POST a new JSON object, and GET a list of JSON resources. You PUT a change to a JSON object, and DELETE a JSON object. POST, GET, PUT, and DELETE are all HTTP actions.
When a web page is delivered, it is an HTML document being delivered over HTTP. With a JSON API, it is the HTML element that is replaced, and not the HTTP. It’s JSON over HTTP.
What I’m referring to is the fact that you can query response.headers in Rails (I’m assuming response.status is derived from them). In my opinion with JSON there should be none of those for response status. The status codes and response should be completely within the JSON response. The fact that resonse.headers includes a status result with JSON responses can lead to confusion. I’d rather the JSON API be responsible for the requests status codes and have the added benefit of its own additional error codes.