handmadeFromRuя ответил давно тебе и про коды, что они дают, но ты мне написал на это "дурачек" потому что ты так не считаешь, ахеренная аргументация)
я тебе дажe книжку скинул, но снова свое гнет. ладно все я пас. ничего не берет тебя.

Вообще-то ты всё свёл к тому, что пофигу чё там кто использует, это не принципиально.

Я топлю за обоснованный, осмысленный, аргументированный подход.

И вообще ты сказал "http - это не просто транспортный протокол. это протокол уровня приложения.", т.е. коды ошибок HTTP проходят по бизнес-логике и все его тонкости в ней отображены. Я в это не поверил, значит ты перепутал понятия "прикладной уровень" и "уровень приложения".

handmadeFromRuhVosttВообще-то ты всё свёл к тому, что пофигу чё там кто использует, это не принципиально.

нука найди где я сказал что пофигу. я писал что я дальше буду использовать 400, ты дальше 200. и мы живем как есть

Это не продуктивный вывод. Речь шла не о том, кто там что используем, ходит ли в трусах по офису или ещё какую фигню вытворяет.

handmadeFromRuя тебе привел свои аргумент, ты их обосрал и говоришь что не было аргументов

Ты не приводил аргументов, ты критиковал мои, и при этом так и не ответил на простые вопросы.
И вот это странно )

handmadeFromRuэто не я сказал, так говорил rfc. прям в начале текста.
хвост я не писал что HTTP проходит по бл. в бл возникает ошибка и она выкидывается. контролер решает каким кодом ответить. http отражает состояние запроса.

Ну это же неправда. RFC ничего подобного не утверждает. Bad Request говорит о том, что запрос составлен корректно, об это говорится. С точки зрения бизнес-логики нет никакого "запроса". Это прикладной уровень взаимодействия.

Хорошо спроектированная архитектура изолирует бизнес-логику от протокола. Т.е. ты можешь её использовать напрямую, где нет никаких кодов.

Давай посмотрим на изначальный вопрос ТС?

WaspNewCoreКак сообщить клиенту, что что-то идет не так. Речь не об ошибке 500. А о том, чтобы сообщить пользователю что он что-то не корректно ввел и т.д.

Некорректный ввод пользователя, это обычная ситуация. Пользователи часто ошибаются, делают не то. Это предусматривается разработчиками приложений.

Засунуть такие ситуации в Bad Request -- это тупо смешать мухи с котлетами.
Какой от этого вред -- очевидно. Но ты не хочешь его признавать.

Ну и хер с ним. Скажи, какой от этого профит? Для тебя? Нахрена тебе это надо? Чем тебе 200 для валидации не угодило?

CalabongaЗачем пониторить ошибки, которые не имеют отношения к бизнес логики? Мне кажется, что у вас, коллега, какая мания сложилась - всё "мониторить"... наверное это возрастное.

Мы просто друг друга не поняли. Я правильно понимаю, ошибки на стороне сервера (не обработанные исключения, невозможность выполнить операцию из-за внутренней ошибки, и т.д.), ты не оборачиваешь в OperationResult, а возвращаешь честный 500?

А ошибки протокола, типа неправильно составленный запрос, формат данных, невозможность адекватно сбиндить полученные данные в модель, это честный 400?

Ну и далее по списку, отсутствие ресурса - 404.
Отсутствие авторизации/доступа - 401/403.

Если углубляться, по REST, то 201 на созданный ресурс, 204 ответ типа "void" и т.д.

Ну и кеширование/перемещение ресурсов 3xx.

CalabongaЕще раз повторюсь, что я не оборачиваю ошибки HTTP протокола, напимер такие, как 500, потому что это невозможно да и смысла не имеет. Оборачиваются только ошибки БИЗНЕС-логики. Да и то, ошибка ошибке - рознь, всё хорошо в меру и с умом. :)

Да. У нас просто возник дискоммьюникейшен )

Дмитрий МухhVosttУ нас просто возник дискоммьюникейшен
На 14 страниц

Ну хоть какое-то оживление )