`invalid_request` — это не ошибка. Это крик в пустоту.

`invalid_request` — это не ошибка. Это крик в пустоту.

Сценарий простой: 2:00 ночи, релиз горит, разработчик в панике подключает ваш API и получает голый статус. Ни поля сломались, ни что исправить, ни где искать причину. Итог: 40 минут тыканья вслепую, потом злое письмо в поддержку и минус доверие к продукту.

Что тут ломает DX:
- ошибка без причины = нулевая диагностируемость
- нет next step = пользователь застревает
- нет контекста = саппорт получает лишний трафик

Нормальный API — скучный и предсказуемый. Это комплимент.
Хорошая ошибка отвечает на 3 вопроса:
1. Что сломалось?
2. Почему?
3. Что делать дальше?

Стандартный путь — приводить ошибки к RFC 9457: тип, заголовок, статус, подробности, ссылка на документацию. Но главное не стандарт, а человекочитаемость. Ошибка должна сокращать время до первого успешного вызова, а не растить его.

Шаблон простой:
- `code`
- `message`
- `details`
- `field`
- `fix`

Если в ответе этого нет — вы не помогаете, вы тормозите 📉