Add separate fields for validation errors

[rijkvanzanten]

The API can return more than one validation error on posting / updating items. For example: wrong datatype and too long.

In order to make the error more useful, we should change the error message structure to something like:

{
  "code": 4,
  "message": "There was a validation error on the fields",
  "info": [
    {
      "field": "name",
      "message": "This value should not be blank.",
      "code": 15
    },
    {
      "field": "age",
      "message": "The maximum length has been exceeded",
      "code": 20
    }
  ]
}

[wellingguzman]

Trying to add a unique field type that already exists in a collection can throw one multiple errors.

Ex: trying to add a primary key and sort field to a collection that already have them.

[rijkvanzanten]

Maybe this is cleaner

One error

{
  "error": {
    "code": 123,
    "message": ""
  }
}

Multiple errors (eg validation)

{
  "error": [
    {
      "code": 123,
      "message": ""
    },
    {
      "code": 123,
      "message": ""
    },
    {
      "code": 123,
      "message": ""
    }
  ]
}

[wellingguzman]

From #7

---

In an error like:

{code: 4, message: "hidden: This value should not be blank."}

It's quite hard to get the field (hidden) out of the message programmatically. It would be nice if these variables could be extracted into their own fields as well:

{
  "code": 4,
  "message": "hidden: this value should not be blank",
  "field": "hidden"
}

That way, I can use them to translate the error messages dynamically

[benhaynes]

@wellingguzman what's the status of this one? Do we need to discuss further?

[wellingguzman]

@benhaynes still in the discussing state. We need to really figuring out how we are formatting the attributes.

We agreed on the error key to be either an object or an array (multiple errors), but we need to find a way to standardize the attributes that works for any case and not just input validation.

Originally suggested to add a new property named field, this may work, but maybe is specific to user input validation.

Another suggestion I think may be better is adding an attributes property with a list key-value.

Something like this:

{
    "error": [
        {
            "code": 200,
            "message": "name: this value should not be blank",
            "attributes": {
                "field": "name"
            }
        },
        {
            "code": 201,
            "message": "age: this value should be numeric",
            "attributes": {
                "field": "age"
            }
        }
    ]
}

Example: the error code will means: 200 = Blank/Required value, 201 = Expected number value.

In this case you should expect any error ranging from 200 to 299 will have an attributes.field property.

This is my suggestion, Happy to discuss this further.

[benhaynes]

That makes sense to me! I'll defer to you two on this one's formatting.

@rijkvanzanten – any thoughts on Welling's proposed approach?

[rijkvanzanten]

LGTM!

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[benhaynes]

To achieve better clarity/visibility, we are now tracking feature requests within the Feature Request project board.

This issue being closed does not mean it's not being considered.