на самом деле мне нравится идея, что мы можем отделить неожиданные ошибки от ожидаемых

```

$.ajax(endpoint_url).then(OnResponse).catch(OnServerError)

```

Но реализация - отказаться от http-кодов - меня сильно смущает. Мне не кажется, что это удобно.
Еще я не видел, чтобы кто-то так делал на практике из больших дядь. (напрмиер, гитахб, амазон, страйп)

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

посмотрите graphql error handling
https://medium.com/@sachee/200-ok-error-handling-in-graphql-7ec869aec9bc

Вот для этого, например. Или для других библиотек, которые уже понимают коды (curl).

$.ajax(endpoint_url).then(OnSuccess).catch(OnError)

Я не то чтобы против вашего подхода. Можно сделать, как вы хотите. Это не что-то ошибочное на мой взгляд.
Я вообще спорил с тем, что этот подход сильно лучше и упрощает жизнь. По-моему, не сильно и не упрощает

а graphql это не restful api, про который, я думал мы говорим :)

эм.. подытожу свою позицию.

Приложение (http api) может возвращать коды статусов, чтобы облегчить клиенту понимание того, какая ошибка возникла.
Внутри ответа должно быть описание ошибки и может быть более специфичный код ошибки от самого приложения.

Можно сделать без http статус-кодов, с обработкой на уровне клиентского приложения, но это вряд ли упростит клиентское приложение.

UPD.

Добавлю, что http статус позволяет сделать какой-то мониторинг на уровне инфраструктуры. Можно подключать готовые тулзы, которые ничего не будут занть про структуру ответа. Например, метрики на уровне api gateway (если есть) или мониторинг ошибок по логам nginx

Или можно легко подключить готовый сторонний healthcheck-мониторинг, который не умеет смотреть в тело, а только на коды.

пример
есть страничка на которой 2 списка: ToDo и Done
и можно из одного в другой перетаскивать drag-n-drop Tasks
пользователь открыл 2 экземпляра страницы
и на одной перетащил таску в Done
теперь он на 2ой вкладке пытается сделать то же самое
серверное апи должно ответить ошибкой, что такое сделать нельзя, тк таска уже в Done
это должно попадать в логи nginx/итд как 4xx/5xx?

Как вариант, если относиться к этому как к некой команде, можно ничего не делать (команда выполнена? выполнена) и ответить 200 ok, пусть фронт на второй вкладке просто нарисует task в нужной колонке 🙂

придумайте пример "по критичнее" - пользователь пытается 2 раза оплатить один и тот же заказ, удалить одну и ту же сущность, создать одну и ту же сущность с констрейтом на уникальность

По желанию, наверное. Я бы хотел видеть это в логах и в мониторинге, чтобы выявлять проблемы.

В обоих случаях просиходит что-то неожиданное для пользователя и на это надо обратить внимание, чтобы исправить ситуцаию с UX

я за go'шный подход к ошибкам
ошибки - это не исключения, а всего лишь другая ветка исполнения кода
то что с точки зрения use case/user story является ошибкой не должно являться исключением для бизнес логики, которая это поведение описывает
поэтому "смогли перетащить - ок, отрисуй в новом списке", "не смогли перетащить - ничего страшного, верни где было и покажи пользователю сообщение об "ошибке""

оба этих случая ожидаемы и не являеются "ошибками"
а вот если в ответ пришло "418 I'm a teapot" с непонятным телом - вот это уже исключение и настоящая ошибка - наша бизнес-логика не предполагает такого поведения

хорошая точка зрения

Я не совсем понимаю, как это связано с тем, что коды ответа вставляются в http заголовки.
Ведь всегда можно не обращать на них внимание, если они не нужны на клиенте. Зато они могут пригодиться в другом месте.

В прочем, если они нигде и никогда не используются, то, дейстивтельно, можно и не париться о них в приложении и всегда отдавать 200.

https://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%B8%D0%BD%D1%86%D0%B8%D0%BF_%D1%80%D0%B0%D0%B7%D0%B4%D0%B5%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F_%D0%B8%D0%BD%D1%82%D0%B5%D1%80%D1%84%D0%B5%D0%B9%D1%81%D0%B0
Принцип разделения интерфейсов говорит о том, что слишком «толстые» интерфейсы необходимо разделять на более маленькие и специфические, чтобы программные сущности маленьких интерфейсов знали только о методах, которые необходимы им в работе. В итоге, при изменении метода интерфейса не должны меняться программные сущности, которые этот метод не используют.

Ну я не знаю, что тут сказать. Я же это же и сказал.
Если на клиенте совсем не используются http статусы, то приложение может их и не ставить.

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

При этом приложение может их ставить, а клиент может от них не зависеть.

Решил вспомнить, с чего все началось :)

Привет всем! Вопрос такой - как православно вертать всякие ошибки в рест апи. Писать заголовок 200 и оформлять ошибку как json (описание всякое там, поля опять же) или возвращать http код типа 403?

не надо, не зацикливай чат!