Echo, chi и свой Validation-хук

Echo объявляет тип type Validator interface { Validate(i any) error } — один метод, и весь контракт: примите что угодно, верните ошибку, если данные плохи. В старых релизах v4 сигнатура встречается с interface{} — это тот же тип под старым именем, компилятор вашу реализацию примет в обоих написаниях. Реализация поверх validator v10 — считанные строки: структура с полем *validator.Validate и метод Validate, который вызывает Struct(i). Назначение — присваиванием: e.Validator = &CustomValidator{validate: validator.New()}, и с этого момента у каждого echo.Context есть рабочая c.Validate(i). Присваивайте сразу после e := echo.New(), до регистрации маршрутов: поле ничем не защищено, а влияние на живом сервере — гонка. Здесь же, в конструкторе валидатора, пропишите регистрации из десятого и одиннадцатого уроков — свои теги и структурные правила — один раз, при старте. Проверка структуры идёт по тегам validate: словарь никто не переключал, и структуры, наработанные в чистых v10-проектах, переезжают в Echo без правки. Контракт Validate(i) на вашей стороне: валидатор ждёт указатель на структуру — за ним идут правила; передать значение-не-структуру можно, но Struct ответит InvalidValidationError из пятого урока, и это ошибка программиста, а не данных. Удобный шаблон — отдельный пакет валидации: конструктор собирает validator.New(), выполняет регистрации и возвращает готовую реализацию echo.Validator; в main остаётся одна строка присваивания, а тесты собирают тот же пакет без HTTP.

Явность Echo расставляет роли по местам. c.Bind — раскладка: path-параметры, query, тело по Content-Type; на правила она не смотрит вовсе, и читаемый JSON с мусорными значениями развяжется без единой ошибки. c.Validate — правила: то, что вы назначили в e.Validator. Склейка — три строки вашего хендлера, и между ними есть место, которого нет в gin: нормализация. TrimSpace перед required, lower-case перед уникальностью — всё это делается между bind и validate, и конвейер bind → normalize → validate становится контрактом проекта: нормализуй, потом проверяй, потому что правила отработавшие на грязных данных бесполезны. Обратная сторона явности — забытый шаг: пропустили c.Validate — компилятор молчит, тест с валидным телом зелёный, а мусор едет в базу до первого ручного теста. Лечение дисциплинное: единый шаблон хендлера в команде, код-ревью на строку c.Validate и тест с битым телом на каждый эндпоинт — тесты правил из девятнадцатого урока здесь закрывают дыру. Ошибки двух шагов разводите с самого начала: c.Bind вернул ошибку — это проблемы транспорта, и сообщение не должно намекать на поля; c.Validate вернул ValidationErrors — это данные, и клиенту нужны детали по полям. Один и тот же echo.NewHTTPError(http.StatusBadRequest, err.Error()) на оба случая — самая частая небрежность Echo-проектов: она прячет тип ошибки и лишает фронтенд различия между «не смог прочитать» и «не прошёл проверку». Как именно устроена нормализация и почему её место именно там — отдельный сюжет пятнадцатого урока.

chi не навязывает даже bind: тело запроса читает кто угодно и как угодно, обычно json.NewDecoder прямо в хендлере. chi валидация поэтому выглядит как функция-хелпер: декодировали, проверили, вернули ошибку — и каждый хендлер зовёт её одной строкой. Тело http.Request — io.ReadCloser, который читается один раз, поэтому валидация не может жить в middleware до хендлера: middleware, прочитавший Body, оставит хендлер с пустым потоком. Декодирует тот, кто владеет данными, — хендлер, — и проверка структурой естественным образом живёт рядом. Ошибки — без сюрпризов: json-декодер даёт свои ошибки, validate.Struct — ValidationErrors, и errors.As разводит их на две ветки: детали по полям или честное «битое тело». Экземпляр валидатора — пакетная переменная или поле сервиса: ровно один на приложение, регистрации на старте. Перед декодом полезно ограничить размер тела: http.MaxBytesReader(w, r.Body, n) ставит потолок байт и возвращает ошибку при превышении — без него один гигантский POST способен занять память процесса. Обёртке нужен ResponseWriter, поэтому лимит ставят в начале хендлера; превышение приедет обычной ошибкой чтения в общую ветку «битое тело». Если хочется одинаковости с Echo, хелпер decodeAndValidate становится вашей реализацией того же Validation-хука — интерфейс чужой, идея общая.

Явные конвейеры возвращают вам право выбора статуса, и тут же возникает вечный спор: 400 Bad Request или 422 Unprocessable Content. Логика 422 красивая: тело синтаксически разобралось, семантика провалилась. Но по факту большинство клиентского кода, документаций и прокси привыкло к 400, а детализация по полям и так отличает валидационный отказ от битого JSON. Историческая справка для спора: 422 придумали в WebDAV (RFC 4918) как Unprocessable Entity, позже её переварили общие спецификации HTTP — в RFC 9110 она называется Unprocessable Content. Статус законный, но не обязательный: 400 тоже покрывает синтаксически корректный, но бессмысленный запрос, так что выбор — конвенция команды, а не требование стандарта. Моё правило: выберите один статус для всех валидационных отказов проекта, пропишите его в константе и не спорьте второй раз — консистентность важнее каноничности. В Echo решение живёт в месте оборачивания ошибки — лучше всего прямо в CustomValidator, чтобы хендлеры вообще не думали о статусах; в chi — в хелпере; в gin — в respondFields. Единый формат ошибок API с кодами и деталями — тема двадцать четвёртого урока, а здесь зафиксируйте принцип: одна точка, где ValidationErrors становятся ответом, и один статус на проект.

Соберём три урока в одну точку. Ваш CustomValidator Validate не обязан быть однострочником: это законное место для нормализации перед проверкой, для StructPartial в PATCH-обновлениях, для конверта ошибок из каталога шестого урока. Структурные правила одиннадцатого урока регистрируются на том же экземпляре — и passwordmatch автоматически заработает в c.Validate без единого изменения хендлеров. Свои теги RegisterValidation — туда же. В chi всё это живёт в decodeAndValidate или в вашем типе с методом Validate, который хендлеры дергают после декодера: интерфейс другой, наполнение то же. Так проект получает то, что gin дал из коробки, но прозрачнее: bind и validate разделены, нормализация имеет своё место, а правила — одни и те же в HTTP-хендлерах, фоновых задачах и тестах. Сам хук легко тестировать без сервера: соберите CustomValidator с реальным движком и прогоните валидные и битые структуры через Validate — это обычные юнит-тесты; в httptest остаётся проверить, что хендлер правильно оборачивает ошибки. И да, это осознанный повтор формулы: одна библиотека, один экземпляр, один словарь тегов — три фреймворка перестают быть тремя мирами валидации.