Resource Validation

[spersico]

It would be cool, if we could add some kind of validation for resources, so that APIs can just define fields that should be validated at the moment that a resource is created/updated.

I believe that we could add this feature, by adding a new static property in the Resource definition, something like this:

export default class Article extends Resource {
  static schema = {
    attributes: {
      body: String
    },
    relationships: {
       /...
    }
  };
  static validators = [checkIfHasBody];
}
// each validator would have the previous state and the proposed one, 
// that way, it can know if its a ADD or an UPDATE operation
async function checkIfHasBody(article, previousState = null): Promise<void> {
  if (!String(article.body).trim()) {
    throw JsonApiErrors.BadRequest(`body is a required field`);
  }
}

The validation could be done asynchronously, to allow for validations dependant of other resources, and It would have the entire object to check, to allow for multi-field validations.

The function could be run at the ADD/UPDATE operations, and intercept those operations if the validation function throws an error. That error could be passed to the user making the request.

[joelalejandro]

It'd be interesting to see this pattern with decorators:

@Requires("body", /* more attributes! */)
export default class Article extends Resource {
  // happy resource lives here
}

Or something more declarative, like:

@Validate(Attribute("body").IsRequired, /* ... */)
export default class Article extends Resource {
  // happy resource lives here
}

[spersico]

It'd be interesting to see this pattern with decorators:

@Requires("body", /* more attributes! */)
export default class Article extends Resource {
  // happy resource lives here
}

Or something more declarative, like:

@Validate(Attribute("body").IsRequired, /* ... */)
export default class Article extends Resource {
  // happy resource lives here
}

I think this approach it would be really cool too!. Especially the second one, 'cause it has more possibilities for custom validators :-)
well... except when there's a lot of props, with a lot of validators, then the decorator begins to get really big, and I start feeling that it's too much for a decorator to handle (in my head, decorators are always kind of small, and a 5+ lines of decorator feels wrong, correct me if i'm wrong).

For example, I can imagine a User resource, with a SSN/DNI format validator, a lot of attributes existence validator, a password complexity validator, an email format validator, and a nickname/email not-used-already validator.