Standardize error responses in v2

[kueda]

In v1, the body of an error response generally looks like

{"error": "Unauthorized", "status": 401}

but if there's an error from the Rails app with a response body it looks like

{"error":{"original":{"error":"You need to sign in or sign up before continuing."}}, "status": 401}

IMO, it would be more consistent and better for clients if Rails errors with a single error attribute just looked like

{"error":"You need to sign in or sign up before continuing."}, "status": 401}

What's less clear to me is what to do with the Rails response includes an errors attribute that could be an array of strings or an object keyed by model attribute names. Should we attempt to standardize those responses? From the client's perspective, is it better for error always to be a single string describing the error, or is it ok to have the response also have an errors attribute that is an array or an object?

[devsnice]

Can it be array with 1 or more errors? I believe the consistency here much better for clients, because a client doesn't know on which level an error happened and it would be easy to work with an array from my perspective

{
  errors: [],
  status: int
}

Much more interesting is how to work with an object error keyed by model attribute names, it depends on how clients use it and do clients need to know what model was produced this error. Probably we can flat object to some string, something like "Model's error: error body"

[kueda]

Yeah. We can do this in a number of ways, just trying to figure out what the right balance between ease of maintenance and utility to clients. Good to know you'd prefer an array of messages. 99% of the time it will be an array with one item, though. It's really only 422 errors that will have multiple separate problems that we might need to communicate to the client.