![](http://webcf.waybackmachine.org/web/20211007033449im_/https://habrastorage.org/getpro/habr/avatars/37e/901/7ad/37e9017adfefa7230e42053d593ff159.jpg)
Как работать с ошибками бизнес-логики через HTTP
![](https://webcf.waybackmachine.org/web/20211007033449im_/https://habrastorage.org/getpro/habr/upload_files/6fd/664/941/6fd664941ff6a3788404554e1d777252.png)
Почти все разработчики так или иначе постоянно работают с api по http, клиентские разработчики работают с api backend своего сайта или приложения, а бэкендеры "дергают" бэкенды других сервисов, как внутренних, так и внешних. И мне кажется, одна из самых главных вещей в хорошем API это формат передачи ошибок. Ведь если это сделано плохо/неудобно, то разработчик, использующий это API, скорее всего не обработает ошибки, а клиенты будут пользоваться молчаливо ломающимся продуктом.
За 7 лет я как поддерживал множество legacy API, так и разрабатывал c нуля. И я поработал, наверное, с большинством стратегий по возвращению ошибок, но каждая из них создавала дискомфорт в той или иной мере. В последнее время я нащупал оптимальный вариант, о котором и хочу рассказать, но с начала расскажу о двух наиболее популярных вариантах.