API Errors

gistfile1.txt

# Example Error failing to validate the requesting client.
{
  'errors' : [
    'The client you are using did not sumbit a client code, please contact your Virtual Hold Administrator'
  ]
}


# Example Error failing to validate a model (User).
{
  'errors' : [
        'Password must be at least 6 characters long',
        'First name can't be blank'
  ]
}

Clean, and pretty consistent compared with what we have been doing in the other API projects.

I like where you are going.

• It seems to me that each of your messages in the "validate" example relates to a separate validation error. Rather than having multiple messages, would it make sense to use the error collection that you have already established?
• It seems to add complexity to have an object that only has one property and that one property is a collection of errors. Is there a reason for having those two layers of nesting, instead of just returning a collection of errors?
• Not related to complexity: What benefit does the consuming developer get from the "type" field? Is it to provide developer messages, since the messages included seem intended for dislpay to end users?

@bbrotherton
My thoughts were more centered around a situation where we had several different types of error messages that occurred on one api request. The type could be used to help filter them out, but I'm not sure if that situation would actually ever come up.

I updated the gist to reflect using only an array.

@benjaminws

Thoughts?

I was mostly trying to get some more information.

What if we do something like this instead:

{
    "errors": [
        {"type":"v", "message":"x"},
        {"type":"v", "message":"other x"}
    ]
}

It would allow messages of multiple types to be passed and each would have its own type. It seems like each validation violation would be a separate "error".