WaspNewCore,

Я использую договоренность с нашими "бэкэндирами" - если не ошибка сервера (не 500), то всегда возвращают 200, а результате отправляю OperationResult, где есть Т - результат, Exception, + метадата...

Calabonga,

Забыл ссылку вставить OperationResult

Petro123Calabonga OperationResult
авторЗаказ добавлен в корзину.
Презервативы закончились на складе.
В корзине уже есть такой товар.
Нет ответа. Ошибка сервиса или сервис не доступен.

смешивание бизнес логики и системной по протоколу

Никакого смешивания при моём подходет - нет! Объясню ниже и по пунктам. А что касается выдачи системых ошибок "наружу" - это еще тот вопрос. Более того, наоборот, загружать пользователя ошибками и бизнес-логики, и системы, в принципе не имеет смысла! Информация о системных ошибках (например, 500) никоим образом не сделают счастливым их получателей. Поэтому я и не смешиваю ошибки протокола HTTP и бизнес-логики. То есть если сервис работает - всегда 200, а если нет, то это уже другая история и тут OperationResult не поможет. И опять же, для ошибок бизнес-логики при использовании OpertionResult (или любой другой "обертки") у меня есть возможность более информативно описать случай бизнес-логики на сервере.

Теперь про "смешивание"
Ну, во-первых. В том-то и дело, что ошибки системы для конечного пользователя не нужны (я говорю например про SPA), а ошибки "user friendly" - это работает "на УРА". Мы их просто "пробрасываем" до пользователя исключая бизнес-логику по их обработке на стороне клиента.

Во-вторых, когда случается "Ошибка сервиса или сервис не доступен.", тогда OperationResult не может быть результатом ответа по опледелению. То есть при таких ошибках OpertionResult не работает. :)

В-третьих, если API работает для внешних сайтов (сторонние пользователи API, не наш GUI), то для них просто в свойство Exception у OperationResult "идут/не идут" (путём включения "галки" в настройках) системные ошибки, вернее сказать, не "системые", а "ошибки более низкого уровня".

В-четвертых, при использовании OperationResult написание unit-тестов для меня существенно упрощается.

В любом случае, данная практика отточена на протяжении более 10 лет использования.
И, кстати, OperationResult позволяет максимально близко реализовать принципы описанные здесь

hVosttCalabonga,

Мне кажется оборачивать всё OperationResult, это попытка изобрести очередной велосипед, скрестив идеи RPC и REST в некоего монстра, который не дружит ни с кем и ни с чем.

В общем, в одном доставшемся нам проекте мы выпиливали "гениальные" обёртки всего и вся в 200.
Потому что страдали все.

Строго не рекомендую подобный подход.

Тяжело судить, что и почему вы там выпиливали, но могу со всей ответственностью заявить, что никогда не было проблем! Только профит! И на UI и на Backend.