В системе существует возможность статической валидации schema, и с помощью него мы можем разработчику указывать, какие обязательные поля в API не были указаны, или неправильно оформлены.
Предовтращает принятие нулей, и перекладывает момент статической валидации с самого роута в отдельную, понятную схему.
По умолчанию все поля описаны в нашем OpenAPI Swagger
Пример работы
На примере создаётся реквест ADMIN RESTful JSON API, с неправильной датой и не указанием дополнительных полей, но система данный реквест не приняла, объяснив причины.
Поле 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 - функция валидации
