Это ошибки разной категории. Неправильные входящие данные это один род ошибок, а «уже существует» - другой

Но вообще я не тулила бы проверку существования email в валидацию. Потому что хорошее rest api на неправильные входные данные должно отвечать статусом 400 bad request, а в случае если email уже существует - 409 Conflict

В хорошем rest api каждый ответ имеет свой правильный статус. И к примеру в системе мониторинга мы следим за ошибками и видим что сегодня было столько то 400х ошибок, столько 409х, столько 500х

А что именно дает конфликт, полей может быть много? Как вывести фронту ошибку?

Это ошибки разной категории. Неправильные входящие данные это один род ошибок, а «уже существует» - другой

Http ответ содержит статус и body.

Вот мне и интересно почему другой. И что от этого лучше? Нода насквозь вся асинхронная, а тут на тебе.
Когда работал на php, то во многих валидаторах проходит полная валидация от типа до наличия в базе и все так пишут.

Та писать можно как хотите. Но у нас поатежная система через нее каждый день ходят деньги. Настроен тщательный мониторинг за каждым статус кодом. Много 400х пошло значит кто то ломится с неправильными данными. Много 409х или 403 значит тоже нужно посмотреть что такое. Если бы все ответы были 200 не получилось бы мониторить аномалии.

Интересно с точеи зрения разделения ответственности, почему принято схему отдельно, а теперь ручками проверять другие моменты.
P.S. Коды можно вывести при любой реализации это не имеет отношение к вопросу

если с сервера приходит статус 200 и, при этом, в теле ответа что-то вроде errors: [...], то, как гласит мем, – "всех – на переработку"

На переработку, видимо, надо отправить весь гугл, Фейсбук, Яндекс... Да всех, кто отличает ошибки бизнес-логики от других ошибок (протокола, доступа и т.п.) То есть практически все успешные компании

На переработку, видимо, надо отправить весь гугл, Фейсбук, Яндекс... Да всех, кто отличает ошибки бизнес-логики от других ошибок (протокола, доступа и т.п.) То есть практически все успешные компании

Пишите руками, не используйте библиотеки из npm

Вопрос @tshemsedinov  и всем про валидацию.

Есть POST запрос c телом:
{
email: "asd@das.com"
}

Хочется получить ответ при ошибках:
{
 errors: {
   email: [
     "Необходимо ввести это поле",
     "Не правильный формат для email",
     "Такой email уже есть в базе"
   ]
 }
}

Все библиотеки, которые я находил (joi, superstruct, ow) делают СИНХРОННУЮ валидацию схемы (первые два варианта ошибки), АСИНХРОННУЮ (третий вариант) принято обрабатывать в бизнес логике и потом также подводить к такому же формату.

1) Почему не сделать валидацию асинхронной и завести в нее проверку третьего случая?
Это упростит обработку ошибок и вывод их в апи, т. к. все будут работать через один механизм.

2) Кто какой использует валидатор?

P. S. Нашел только одну библиотеку которая делает валидацию ассинхронно - async-validator, но она имеет баги и слабовата.

В таком случае при нахождении длины гипотенузы не используйте теорему Пифагора. И каждый раз выводите ее сами.