В системе существует возможность статической валидации schema, и с помощью него мы можем разработчику указывать, какие обязательные поля в API не были указаны, или неправильно оформлены.
Предовтращает принятие нулей, и перекладывает момент статической валидации с самого роута в отдельную, понятную схему.
По умолчанию все поля описаны в нашем OpenAPI Swagger
Пример работы
На примере создаётся реквест ADMIN RESTful JSON API#/portal/addArticlePortal, с неправильной датой и не указанием дополнительных полей, но система данный реквест не приняла, объяснив причины.
Поле date не валидно (указан требуемый тип), поле portalMenuId отсутствует, и title отстутствует.
Техническая часть
Все валидации на уровне модуля, по умолчанию, должны находиться в его корневой папке в файле под названием Validations.pm (пример: modules/Portal/Validations.pm
)
Пример такого файла, с комментариями:
package Portal::Validations; use strict; use warnings FATAL => 'all'; # Обязательно для экспорта use Exporter; use parent 'Exporter'; # Указываем в экспортах схемы валидаций our @EXPORT = qw( POST_PORTAL_ARTICLES ); our @EXPORT_OK = qw( POST_PORTAL_NEWSLETTER ); use constant { # Объявляем схему константы POST_PORTAL_ARTICLES => { # Указываем поля, которые нужно валидировать TITLE => { # Поле должно присутствовать required => 1, # Тип поля type => 'string', # Для "string" - минимальная длина min_length => 5, # Для "string" - максимальная длина max_length => 25, }, DATE => { required => 1, type => 'date' }, PORTAL_MENU_ID => { required => 1, type => 'unsigned_integer' }, SHORT_DESCRIPTION => { # Поле может быть не обязательным, но при его присутствии можем валидировать type => 'string', max_length => 600 }, CONTENT => { # Также мы можем указать кастомный тип, и проверять его вручную type => 'custom', function => \&check_content, } }, }; # Функция для проверки поля CONTENT sub check_content { my ($validator, $value) = @_; # $validator при себе имеет объекты db, conf, admin, так что вы можете создавать любой объект и за нужды производить запросы в базу. # Но мы не рекомендуем такой способ валидации, только в совсем узких случаях. if ($value && $value =~ /ABillS/g) { # Успешная валидация return { result => 1 }; } else { return { result => 0, # Мы очень рекомендуем оставлять errstr в string, почему валидация не была пройдена. errstr => 'There is no ABillS in your content.' # Также вы можете прикрепить любое другое поле с объяснением, что не так. # Это может быть любое другое значение, которые может сериализоваться в JSON. some_additional_message => [{ WHERE => 'ABillS' }] } } } 1;
Для того, чтобы использовать валидацию в коде, просто дополните ваш хэндлер дополнительным полем в вашем Api.pm
# Импорт констант валидации use Portal::Validations qw(POST_PORTAL_ARTICLES); sub admin_routes { return [ { method => 'POST', path => '/portal/articles/', # Добавьте константу валидации в поле params params => POST_PORTAL_ARTICLES, handler => sub { ... } } ]}
Существующие типы:
- integer (5)
- unsigned_integer (-5)
- number (1.5)
- unsigned_number (-1.5)
- date (2024-03-28)
- string
- min_length - минимальная длина
- max_length - максимальная длина
- custom
- function - функция валидации