hVosttПарамонТы будешь возвращать 200?

Если это ошибка логики, ошибка ввода пользователем (валидация), естественно это будет 200.
С точки зрения выполнения, это не ошибки, а предсказуемое поведение, нормальная ситуация.

ПарамонНа счёт тысяч ошибок. Главное дать клиенту понять, запрос success или fail, на это статусов хватает. Как твоём случае клиент об этом узнает, чтобы стандартно?

Для чего по-твоему, нужны вообще статусы ошибок HTTP?
Почему бы вообще всегда не отдавать 200, а в теле ответа +100500 кодов и полная информация?

Подумай.

я вот продолжу обсуждение.

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

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

я некоторое время назад сделал подключение к билетному шлюзу Единое поле . даю ссылку на метод создания заказа.

там как видишь подход реализовали
1. успешный ответ - 200
2. успешный ответ + ошибка бизнес логики - ответ 4хх

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

вот реальный пример успешного запроса сеансов для контрагента с http ответом 200



и вот реальный пример успешного запроса сеансов для несуществующего контрагента с кодом 404




то есть как бы прозрачная логика - у тебя есть ответ 200 => ты работаешь со списком сеансов. у тебя ответа не 200, а 4xx => ты работаешь с описанием ошибки.

так лучше. критерий "лучше" тут имеет конкретную характеристику - лучше потому что проще.

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

по моему все споры идут из-за того, что в кодах 2xx или 4xx в Http протоколе нет специально выделенного значения для ошибок бизнес логики.
как-то надо обрабатывать ситуацию, когда успешный ответ в принципе есть, но как то надо оповестить о том, что пытаются использовать несуществующего контрагента.

поскольку с обработкой ответов - тут все-таки соглашение, просто надо выбрать подходящий для вашей системы подход.
ну вообще обсуждаем 2 подхода

1. для успешных операций и ошибок логики возвращать 200. в этом случае в ответе нужно заводит поле, в котором может быть записана возможная ошибка логики
2. для успешных операций нужно возвращать 200, для ошибок логики возвращать один код 4xx. в этом случае в случае успешной операции возвращать данные с ответом, в случае ошибки логики возвращать код ошибки и возможное описание ошибки

AddxПарамонhVostt,

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

Весь мир так работает, хочешь оставаться Дартаньяном, пожалуйста )

А можно про весь мир поподробнее? Пару примеров. Да хотя бы один?

я привел пример крупной билетной площадки Единое поле , которая так работает