Валидация ввода для API

Добрый день, спасибо за урок. А будет как - то реализованы коды ошибок? Чтобы фронт знал как необходимо реагировать на ту или иную ошибку.

Дмитрий здравствуйте, не могу понять как работает

/**
 * @Assert\NotBlank
 */

Как вообще могут комментарии влиять на код? Здесь получается мы вызвали метод NotBlank? Как это вообще работает?

Спасибо. Очень интересно.

Дмитрий, после коммита Extracted validation handling ElisDN, psalm стал ругаться на ошибку ERROR: UndefinedDocblockClass в ValidationExceptionHandler::errorsArray на строку $violation->getMessage(). Решил путём установки полифилла composer require symfony/polyfill-php80 --dev чтобы был доступен \Stringable интерфейс

Как поступить в случае, если формат запроса не совпадает с форматом команды? Тогда сообщения об ошибках валидации будут кодироваться неправильными полями. И пользователю будет непонятно к какому полю относится ошибка.

Дмитрий, вы привели пример с валидацией email в объекте Email и поля email в команде. Валидатор email практически стандартный. Но что если нужен кастомный валидатор? Получается его логику придётся дублировать в инициализации объекта/типа и в проверке правильности команды. Подозреваю, что если возникнет ещё один слой с DTO, то придётся и там проверять ещё раз. Например перед записью в хранилище. Но это слабый пример, так как мы доверяем нашей модели.

Добрый день. Заметил один момент - в некоторых фабриках для контейнера Вы используете static function (mailer, errors, http), в других просто function. Выбор того или иного варианта чем-то обусловлен?

Дмитрий, во всем проекте довольно-таки простые команды, они содержат 1-3 поля. Однако в реальном мире, API может принимать большие структуры данных. Например, могут быть вложенные сущности, массивы вложенных сущностей:

{
  "doctor": {
    "first_name": "",
    "last_name": ""
  },
  "patient": {
    "first_name": "",
    "last_name": ""
  },
  "medications": [
    {
      "name": "",
      "count": ""
    },
    {
      "name": "",
      "count": ""
    }
  ]
}

Как быть в таких ситуациях?

Познакомили с новой технологией, спасибо Дмитрий!

Применяя Symfony Validation + используя рассмотренный подход (Command=DTO), я сталкиваюсь с парой концептуальных проблем. Просьба растолковать, как их избежать.

Проблема первая:

Такой Command после валидации уже нет возможности использовать в качестве полноценной DTO в дальнейшей доменной валидации и дальнейшей обработке.

Почему? Потому что поля объекта Command в нашем сценарии уже не могут быть типизированными, но должны быть mixed, что сильно снижает ценность объекта как DTO и удобство извлечения из него данных.

Почему? Потому что когда мы хотим, например, проверить что в строке реквеста прилетел int (целое число) а не что то иное (float - 123.50) (или наоборот нам нужен float), то мы применяем проверку ПОЛЯ объекта на int или на float:

/**
 * @Assert\Type(type="integer")
 */
public $intProperty

Но чтобы это работало, тип поля должен быть без указания типа (mixed), иначе, если поле будет

public int $intProperty

то Validation будет всегда определять его содержимое как int - всегда будет приведение типа к int при присваивании этому полю строки запроса.

Какие есть варианты сохранить типизированный феншуй?
Делать второй нормальный типизированный DTO на основе Command и отправлять его дальше?
Это весьма костыльно.

Подскажите пожалуйста, Дмитрий: как элегантно пользоваться validation и сохранить удобный типизированный DTO для дальнейшей обработки ?

А вот вдогонку. Проблема вторая:

В своём проекте, в исключениях (Exception) мне мало одного поля message, поэтому я использую два разных сообщения для одной ошибки - для пользователя и для логов. Типа того:

abstract class BaseException extends Exception
{
    private string $logMessage;

    public function __construct(
        private string $userMessage,    // для блондинок: ваш платеж не прошел - сообшите в поддержку
        ?string $logMessage             // детальное, для гиков в логе: ответ api банка итд
    ) {
        if (!$logMessage) {
            $logMessage=$userMessage;
        }
        $this->userMessage=$userMessage;
        $this->logMessage = $logMessage;

        parent::__construct($logMessage);
    }

    final public function getUserMessage(): string
    {
        return $this->userMessage;
    }

    final public function getLogMessage(): string
    {
        return $this->logMessage;
    }
}

class ValidationException extends BaseException
{
    public function __construct(
        string $userMessage,
        ?string $logMessage=null
    ) {
        parent::__construct($userMessage, $logMessage);
    }
}

и при ловле моего Exeption:

try {
    do something; 
} catch (ValidationException  $exception) {
    ShowUserMessage($exception->getUserMessage);
    $logger->error($exception->getLogMessage);
}

И все было прекрасно пока я не познакомился с Symfony Validation, в котором есть так много вкусных проверок, но предусмотрено только одно сообщение об ошибке(Message).

Дмитрий, как посоветуете использовать Symfony Validation с сохранением двух разных сообщений об одной ошибке?

Благодарю!

Дмитрий, откройте тайну: почему Вы решили задавать constrains в аннотациях, а не через PHP (ниже пример)? Ведь в аннотация проще ошибиться при множестве правил, а в PHP hinting подсказывает..

use Symfony\Component\Validator\Constraints\NotBlank;
use Symfony\Component\Validator\Mapping\ClassMetadata;

class Author
{
    private $name;

    public static function loadValidatorMetadata(ClassMetadata $metadata)
    {
        $metadata->addPropertyConstraint('name', new NotBlank());
    }
}

Кстати, чтобы включить эту возможность достаточно ли добавить в конфигурации ?

Validation::createValidatorBuilder()->addMethodMapping('loadValidatorMetadata')

Кстати, темп и краткость/подробность подачи материала для меня лично теперь оптимальны, спасибо! А если покажеться что тема не раскрыта - буду вопрошать :)

Здравствуйте, Дмитрий!

Сделал себе обработчик ошибок в middleware, по аналогии из аукциона. Оказалось, что такой код не отлавливает / не логирует PHP ошибки. Только исключения.

Например, в Вашем коде не будет залогирована ошибка несуществующего ключа массива:

$x=array['unexisting'];

Это грустно, т.к. такие ошибки критичны.

Посоветуете ли сделать лог ошибок как здесь? Advanced Notices and Warnings Handling

При обработке ошибок столкнулся с неприятной вещью:

Отправляю из vanilla JavaScript (browser) fetch() запрос . В бэкенде предусматриваю возврат json ответа в случае ошибки, чтобы ошибку красиво отобразить на фронтенде.

Однако, в случае ошибки возвращается не json, а страшный html который сформирован xdebug. То есть, xdebug нагло "впихивает" в ответ своё html содержимое вместо json ответа.

Может будут идеи как избежать такой навязчивости xdebug? Пусть xdebug отображает ошибки только там, где ему положено - на html страницах.