ПарамонТут могла быть ошибка, и тогда вменяемый сервис вернет 4xx.

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

Ты не в состоянии это пояснить. А долбишь одно и то же, как заведённый.
Это не продуктивно. Да ещё и позорно, тратишь время на прочтение твоих бредовых опусов.

ПарамонРазумеется, тестируют максимум возможных кейсов от клиента, и возврат правельных статусов.

В ASP.NET ошибка 500 приводит в том числе по неотловленному эксепшену. т.е. это явная ошибка программистов ПО. Вы это тестируете? Предсказываете все ошибки?

400 обратный случай -- это явная ошибка клиента, неправильно составленный запрос.

Что вы там тестируете, поведай нам? Потому я пока пребываю в уверенности, что ты придумываешь и врёшь нам.

ПарамонКак уж на сковородке, все смеются уже. Просто скажи - оплата в твоем монимании это теперь уровень протокола и твой сервис вернет "200 + извините, вы не заплатали". )) Ты ведь так прямо и написал в преидущем посте.
Ну или забыл заплатить за протокол, тогда 402

Я не вижу никаких противоречий, смеешься над собой.

Парамонps
Как бы практика серьезных, мировых лидеров в этой области заслуживает внимания, в отличае от форумных Д’Артаньянов.

Практика всегда идёт как доп. обоснование, но никак не основное.
Почему вы так делаете? Что это даёт? Какие преимущества?

Твой ответ:

Так делают в Амазон (и два галимых примера). ПОх. ПОх.

Понимаешь, как ты выглядишь? Не обуссудь.

handmadeFromRuя тебе уже объяснил что по последнему rcf http трактуют как протокол уровень приложения, так как это уровень приложения он должен показывать состояние, там четко написано что 400 это ошибки клиента и не важно какие.

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


handmadeFromRu1. на основе rfc http часть приложения а значит должно отражать его состояние в конкретный момент времени

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


handmadeFromRu2. я могу тестировать апи и понимать что запрос не прошел крайне просто

как ты отделишь на уровне чёрного ящика (не зная формат JSON/XML/etc сообщений) сообщения бизнеса от реальны ошибок протокола?

3. ты не видишь проблемы , потому что ты а) не админ б) никогда не работал в разработке с крупной экосистемой, где есть админы, которые явно тебя скажут об этом в) да хз, ты уже заявлял, что тебе пофигу куда и с каким кодом писать, как фишка ляжет, по настроению... о чём тогда говорить?

4. тоже самое. бизнес-сценарии все тестируются, втом числе негативные. не тестируется работа протокола, никому не придёт в голову тестировать то, как работает сервер приложений, как работает биндинг ASP.NET и т.д., потому что это уже давно протестировано Microsoft и другими компаниями.

моя аргументация пока не поколебима.

love_bach,

404 ты возвращаешь в двух случаях:

1. неправильный URL, для которого не найдено ни одного маршрута, это делает платформа обычно
2. URL правильный, маршрут найден, но ресурс, на который указывает URL (некий ID, например) отсутствует или удален.

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

love_bachПарамонТеперь экзамен.
Какой статус вернет сервис в случае, когда продукт не найден в базе данных?

вооот. меня тоже это интересует!

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

Парамон


Выделенное приводит к ошибке 400.

Валидация, которая говорит о том, что приложение ПРИНЯЛО запрос, ОБРАБОТАЛО и ПОНЯЛО, но ДАННЫХ (которые именно бизнес-данные) что-то не так. В случае валидации это совершенно нормальный запрос, ответом на него должно быть 200.

Так как в случае валидации запрос НОРМАЛЬНЫЙ, а не ПЛОХОЙ. Просто вы пипец ребята не дружите с логикой. И в очередной раз подтверждаете, что у вас в голове каша и мрак.


ПарамонЦена может быть в интервале от 0 до 999.
И так, кто это решает? Это решает бизнес!
Что это значит? Значит, что это чисто бизнес правило ! В другом бизнесе цена может быть от 10 до 3000.
Тут протокол никаким боком не завязан, а просто, так решил продавец пылесоса.
И завра он может это правило изменить, и менять его хоть каждый день.

Ты вообще учавствовал в разработке коммерческих API, или только сам себе на страничку данные слал?

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

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

ПарамонЕсли тестировение выявило ошибку 500, она должна быть исправленна в короткий срок, в отличае от той же 501, которая может ждать, а может вообще так и остатся.
Что здесь сложно понять?

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

Обычно такая ошибка используется в процессе разработки и не доходит до прода. И это удобно, так как не нужно знать подробностей реализации и формат сообщений, чтобы понять, что такой URL обрабатывается, но не реализован.