xmidt-org / ears

Event Async Receiver Service (EARS)
Apache License 2.0
4 stars 7 forks source link

Struct/Data validation - which tools to use #55

Open gtrevg opened 3 years ago

gtrevg commented 3 years ago

Background

There are a number of cases where we need to apply some sort of data validation:

Each may have unique constraints that should be addressed. For instance:

CaseConstraints
API
  • One definition to expose (e.g. via OpenAPI spec file) as well as validate
  • Should be lightweight and fast
  • Should be able to drive API error messages and/or codes
Incoming Messages
  • Should be lightweight and fast
  • Should be able to produce specific messages and/or codes
  • Should be easy for a customer to configure the validator
Plugin Configurations
  • Should be able to produce specific messages and/or codes
  • Should be easy for a plugin developer to specify the constraints
  • (stretch) Should be easy for a configuration interface for a plugin to generate a form that enforces validation

Research

A quick search produced the following results

Thoughts

Originally I thought we could lean into json schema (since it can apply to YAML docs as well), but I'm curious how json schema would go about addressing common types, such as UUID, email, URLs.

gtrevg commented 3 years ago

After some testing with ozzo-validation, I ran into issues with it trying to validate pointers to ints. When testing if the i > 1, the result would always pass even when the value was 0. It seems like pointers to ints are not supported.

I then replaced this with gojsonschema validation. Ideally, jsonschema is expressive enough to cover both the sender and receiver validation.

gtrevg commented 3 years ago

We should also look into OpenAPI and see if they have something.

gtrevg commented 3 years ago

https://github.com/getkin/kin-openapi could support validation based on an OpenAPI spec.

There may be a way to use the basic payload validation definition plus an object.