Кто с GraphQL работал, над мемом не смеется.

Решение выглядит по-джуниорски, но у GrpahQL были веские причины сделать именно так.

Прохладная былина как не надо
В Проде перестал отвечать один из сторонних сервисов, возвращающий квитанции. Точнее отвечал HTTP 400 Кодом. Пошли к разработчикам сервиса выяснять. Было несколько версий:
— Такой квитанции нет и никогда не было
— Квитанция есть, но связанные с ней сущности не нашлись
— Нам не хватает прав, чтобы получить эту квитанцию, и сервис делает вид, что её нет
— Изменился URL запроса квитанции

За три часа дебага, вычитки логов и коммитов за последние два дня мы выяснили, что запросы вообще не приходили на сервер. Ни на один. Оказалось, админы поменяли маршрутизацию, и 400 отдавал какой-то левый сервер.

Почему мы так долго возились? Потому что ошибки HTTP-протокола не были отделены от ошибок бизнес-логики. Получил 400 и надейся, что подробности будут в теле сообщения. А там их нет, ахах.

А как в GraphQL
1. Если запрос дошел до endpoint’а, в любом случае вернется HTTP 200 и один из ответов, прописанных в схеме. Например, Receipt | ReceiptNotFound | NotEnoughPermissions.
2. Вернулось что-то отличное от 200 — ищи проблему в инфраструктуре.

Что это даёт:
— Клиенту не надо гадать, какую ошибку вернёт сервер на конкретный запрос. Все прописано в схеме.
— Невозможно спутать ошибку бизнес-логики с инфраструктурной.
— Не нужно обсуждать всей командой, какой код ответа использовать для бизнес-ошибок: “I am Teapot” или что-то более традиционное.

Если у вас нет GraphQL и публичный API
— Выберите какой-нибудь разумный код для ошибок бизнес-логики.
— Никогда не возвращайте 200 и подробности в теле. Разработчики проверят, что вернулся 200 и посчитают, что всё хорошо.
— Снабжайте ответ подробностями: что произошло и как это исправить.

Делайте хорошо. А плохо не делайте. Мир вам.

Кстати, какой HTTP статус вы используете для ошибок бизнес-логики?