Child pages
  • Статическая валидация schema
Skip to end of metadata
Go to start of metadata

В системе существует возможность статической валидации schema, и с помощью него мы можем разработчику указывать, какие обязательные поля в API не были указаны, или неправильно оформлены.
Предовтращает принятие нулей, и перекладывает момент статической валидации с самого роута в отдельную, понятную схему.

По умолчанию все поля описаны в нашем OpenAPI Swagger

Пример работы

На примере создаётся реквест ADMIN RESTful JSON API#/portal/addArticlePortal, с неправильной датой и не указанием дополнительных полей, но система данный реквест не приняла, объяснив причины.

Поле date не валидно (указан требуемый тип), поле portalMenuId отсутствует, и title отстутствует.

Техническая часть

Все валидации на уровне модуля, по умолчанию, должны находиться в его корневой папке в файле под названием Validations.pm (пример: modules/Portal/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 - функция валидации
  • No labels