я б рекомендовал почитать несколько вещей

1. RFC, где описан HTTP. Либо мелкие книжки на тему того, как HTTP устроен, но всё равно лазить в рфц. Это отсечёт очень много вопросов на тему статусов
2. Изучить, как работают хорошие апихи. Людям нравится Страйп и Гитхаб. У гитхаба щас графкл, но можно почитать доку для старых апи.
3. Посмотреть на попытки стандартизовать такие API. Например, https://jsonapi.org/
4. Взглянуть на график в статье https://martinfowler.com/articles/richardsonMaturityModel.html

В современном JS всё равно в HTTP ходят через fetch, и там система с обработкой ошибок понятна — не надо заниматься всякими штуками с 200 статусом и ошибкой в теле. Ошибка в теле может быть полезной, но не стоит полагаться только на неё. Хттп статусы бывают суперполезны.

Вне жса проблем тоже особо нет.

Ещё есть GraphQL, где твои ошибки в запросе всё равно придут в 200. Это норм, но самостоятельно такой протокол реализовывать это ух.

Ну и даже с GraphQL API очень полезны статус-коды, но уже для других целей.

те GraphQL молодцы, что ошибки возвращают как 200, но так делать не стоит? почему? не могу понять вашу логику

самостоятельно реализовать что?

if resp.error != null {
  onError(resp.error);
  return
}

onSuccess(resp.result)

прям ух. сложно)

> GraphQL молодцы, что ошибки возвращают как 200, но так делать не стоит

шо

я такого не говорил

сразу после этого идет «Это норм»

а чуть выше
> не надо заниматься всякими штуками с 200 статусом и ошибкой в теле

а GraphQL занимается.. получается GraphQL делает что-то неправильно?

Тут важно понимать, что то, что графкл связан с хттп — это случайность

Большинство апих в дикой природе — это апихи, которые очень тесно связаны с хттп. Соответственно, проектируются сразу с учётом, что:

* способ коммуникации — исключительно HTTP
* есть наборы урлов с каким-то смыслом
* у ответа может быть тело
* у ответа обязан быть статус

В этих условиях, можно изобрести свой протокол и отказаться от всего тулинга вокруг HTTP, который уже есть. Но цена этого — никакой стандартизации и необходимость реализовывать свои тулзы.

а в спеке графкл я не помню чего-то, что было бы завязано на хттп. это просто дсл для того, чтобы кверить жсончик

а если не пользоваться хттп статусами, то это ещё и лишнюю обработку ошибок в современном жс описывать придётся. ъуъ

У стандартизации есть свои плюсы и минусы. Отказываясь от неё, изобретая свой протокол, придётся платить цену.

Тут важно не само решение, а понимание последствий.

ну раз вы считаете её лишней, то конечно. остается лишь пожелать успехов на этом пути =)

ну щас есть чёткое разделение — успешный запрос и неуспешный, причём хендлинг 4хх и 5хх статусов вполне себе можно разделить, при желании

а наворачивать хендлинг на:

* 200-хороший
* 200-плохой
* не-200

это как-то слишком

я видел выше сообщение

> что бы "почувствовать разницу" попробуйте написать обработчики then/catch для `$.ajax('/api/order/123')`и различить в них когда ошибка от приложухи, а когда от вебсервера

но тут сказать нечего — ССЗБ

это предсказуемый путь из 3х вариантов: 200+ok, 200+error, non-200 (server_error)
обработчики 200 OnSuccess, 200 OnError будут свои для каждого эндпоинта
и то, скорее всего, OnError и OnServerError будут универсальными в единственном экземпляре
четкий интерфейс взаимодействия http транспорта и вашего api

вы же предлагаете делить: 200, 4xx, 5xx, а потом добавлять case для каждой конкретной ошибки отдельно. и вот тут вместо того что бы расширять логику api придется постоянно дописывать логику интерфейса взаимодействия с http

да. понимание последствий очень важно

Два сока этому товарищу

код 200 всего лишь значит, что сервер работает и ошибка на уровне GQL
если бэк прилег — nginx вам все равно вернет что-то отличное от 200 по обстоятельствам.