mojolicious
Data structure validation
Originally we were planning to make JSON::Validator a Mojolicious spin-off project and have the very important topic of data structure validation covered that way. But unfortunately that has not worked out the way we were hoping. So we are going to need a different solution.
On the plus side this means we can aim much lower when it comes to spec compliance. Without the need to support OpenAPI, there is also no need to follow a dozen different versions of JSON Schema. While i do still believe that basing the validation system loosely on JSON Schema has many advantages, we can focus exclusively on what Mojolicious actually needs.
Here's an example for how i imagine the API to look like:
sub some_action ($self) {
return $self->render(json => {error => 'Data structure in JSON format required'}, status => 400)
unless my $data = $self->req->json;
my $v = $self->schema(
{
type => 'object',
required => ['name', 'job_group', 'job_id', 'group_id', 'status', 'distri', 'flavor', 'version', 'arch', 'build'],
properties => {
incident_settings => {anyOf => [{type => 'integer', minimum => 1}, {type => 'null'}]},
update_settings => {anyOf => [{type => 'integer', minimum => 1}, {type => 'null'}]},
name => {type => 'string'},
job_group => {type => 'string'},
job_id => {type => 'integer', minimum => 1},
group_id => {type => 'integer', minimum => 1},
status => {type => 'string', enum => ['unknown', 'waiting', 'passed', 'failed', 'stopped']},
distri => {type => 'string'},
flavor => {type => 'string'},
version => {type => 'string'},
arch => {type => 'string'},
build => {type => 'string'}
}
}
);
my @errors = $v->validate($data);
return $self->render(json => {error => "Data does not match the validation schema: @errors"}, status => 400) if @errors;
...
}
The schema still looks very much like a JSON Schema, but we can be very selective about the features we want to support. Validation errors will be objects, but how exactly they should look internally is still to be determined. I18N needs to be considered, but we also don't want to go too far in that regard.
