|
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
|
|||
---|---|---|---|
#18+
hVostt, зачем мне админам что то объяснять? логи ошибок они проанализирую в ролбаре или в elk туда и попадет 400 стандартная. 400 от бизнес уровня туда не попадут. тестерам эт ваще не помешает. юнит мы сами тестим и тут не важен статус. как http коды помещает qa? почему я не получаю от своих фитбека ..расскажи может я чего не замечаю. http - это не просто транспортный протокол. это протокол уровня приложения. поэтому содержимое запросов и ответов тоже являются частью протокола вот эт прям тут написано https://tools.ietf.org/html/rfc7231 так что 409 и к примеру и создавалась на случай те кто не хотят мешать с 400. да весь стандарт движется в сторону что http для веб приложения это часть его. посмотри старые версии хотя бы стандарта где для 400 было malformed request, стало client error. стандарт http ничего не говорит о типе приложения только о протоколе общения между клиентом и сервером но... веб-сервер и веб-приложение - это две части одного целого и то, и другое работают вместе, чтобы подготовить ответ поэтому, 400 в случае ошибки в бизнес-логике - это нормально, и это ожидаемо но rfc не указывает такой кейс, и не должен указывать его. в rfc просто пишется об ошибке клиента с точки зрения веб-приложения п.с. оффтом не по теме - ты хоть не много задумывался что можешь быть не правым? вот иногда ? да не бред ж это хвост он не ошибаешься ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2018, 10:25 |
|
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
|
|||
---|---|---|---|
#18+
ладно хвост тут больше делать нечего. мы уже поняли друг друга, я дурак для тебя и прочее. давай лучше как нить под пивко такое дискутировать) ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2018, 10:52 |
|
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
|
|||
---|---|---|---|
#18+
handmadeFromRuп.с. оффтом не по теме - ты хоть не много задумывался что можешь быть не правым? вот иногда ? да не бред ж это хвост он не ошибаешься Мало кто может публично заявить, что сглупил. И не переписывать же теперь все свои сервисы. А как с этим жить? Нет смысла дальше спорить и доказывать очевидное. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2018, 10:59 |
|
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
|
|||
---|---|---|---|
#18+
handmadeFromRuзачем мне админам что то объяснять? логи ошибок они проанализирую в ролбаре или в elk туда и попадет 400 стандартная. 400 от бизнес уровня туда не попадут. затем, что твои логи это твои логи. то, что ты туда напишешь -- твоё дело. именно поэтому, с точки зрения администрирования, админу важны выделить работает твоё приложение хорошо, или есть ошибки, при чём БЕЗ знания подробностей реализации. на твои форматы сообщений JSON/XML мониторингу положить, никто не будет в большой экосистеме из кучи сервисов и приложений ковырять и разделять ошибки протокольного уровня от нормальных бизнес-кейсов. handmadeFromRuтестерам эт ваще не помешает. юнит мы сами тестим и тут не важен статус. как http коды помещает qa? почему я не получаю от своих фитбека ..расскажи может я чего не замечаю. вот вы на этом и прокалываетесь. если вам не важен статус, какого хрена вы за него зацепились? оставьте коды ошибок HTTP -- протоколу. а если важен, то уже блин напишите почему? только без детского лепета про амазон и "миллионы" адептов. скажи, нафига тебе в 400 засовывать отдельные бизнес сценарии? или в другой код HTTP ошибки? насчёт тестирования. как только ты в 400 засунешь бизнес, то тестировать придётся все 400, иначе это какой-то шит. а что делать мониторингу вообще непонятно. объяснять ему, что 400 это теперь не проблема протокола, но и вообще что угодно, смотрите в тело, так? для чего эту кашу создавать? ради какой великой цели? просто я не понимать. handmadeFromRuп.с. оффтом не по теме - ты хоть не много задумывался что можешь быть не правым? вот иногда ? да не бред ж это хвост он не ошибаешься я хочу матьево услышать вразумительные аргументы. пока слышу только одно: вон те дяди так делают. ну вот добей меня, скажи, что это безаппеляционный аргумент. я тогда вообще ничё писать не буду. нафиг надо. спорить с какими-то "миллионами" в лице одного человека, это тухлый номер. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2018, 11:12 |
|
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
|
|||
---|---|---|---|
#18+
ПарамонМало кто может публично заявить, что сглупил. И не переписывать же теперь все свои сервисы. А как с этим жить? Нет смысла дальше спорить и доказывать очевидное. Ни о чём. Я указываю на конкретные задачи и проблемы, от вас только неадекватные смешки и бесполезный трёп. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2018, 11:13 |
|
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
|
|||
---|---|---|---|
#18+
handmadeFromRuстандарт http ничего не говорит о типе приложения только о протоколе общения между клиентом и сервером но... веб-сервер и веб-приложение - это две части одного целого и то, и другое работают вместе, чтобы подготовить ответ поэтому, 400 в случае ошибки в бизнес-логике - это нормально, и это ожидаемо С хрена ли? А если приложение будет работать и через REST API, и через, например, веб-сокет, или интеграция через JRPC, и т.п. -- ты что, потащишь свои HTTP коды ошибок во все остальные протоколы? Я не понимаю, с какого хрена смешивание протокола и бизнес-логики это вдруг стало нормальным? С каких пор это ожидаемо? Где об этом написано? В RFC я не нашёл, если буквоедством заниматься. Там написано чёрным по белому примеры, когда применяется тот же код 400. Это явная проблема контракта. Bad Request -- это плохо составленный запрос, невозможно продолжить коммуникацию с таким запросом. На уровне протокола. Если как ты говоришь про "ожидаемо", тогда можно говорить о том, что можно использовать любой код для любых целей какой заблагорассудится разработчику. Так? ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2018, 11:24 |
|
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
|
|||
---|---|---|---|
#18+
Ладно, продолжим. )) hVosttКакой-то детский сад. Если ты уже перешёл на личности, изволь не обвинять собеседника. А то ощущение, что тебе 10 лет, ты ещё скажи "он первый наааачал". Ты заплакал, я утешил. hVosttНет никакой поддержки. Да и доводов по сути ни каких нет. Вообще. И земля плоская )) HTTP response code for POST when resource already exists Which HTTP response code for “This email is already registered”? RESTful Error Responses Приведи, кто с тобой согласен, ну кроме отражения в зеркале и пехапешника? hVosttВ смысле трактовать? Там чёрным по белому написано, что считать ошибками, для чего нужен код, в спеках у мозиллы и других разработчиков всё расписано Расписанно не все, а только основные принципы. Никогда сухое описание стандарта не обходит все кейсы, для более глубокого понимания обычно пишут книги, блоги и тд. Ты просто описываешь тут свое понимание, то есть непонимание, а копнуть глубже не в состоянии. hVosttВот оно. Если если по-твоему каждый придумывает свой респонс , о чём тогда вообще речь? Вот именно, я про тваой подход писал. hVosttТы получил код 400. Что ты из этого понял? То, что проблема в моем запросе, и сервер просит его исправить. К примеру 5xx говорит о другом, 200 говорит "ОК". заметь, "ок, ты ошибся" - звучит глупо hVosttДа пофигу тогда, пиши в любые коды. К тебе пришли за рекомендациями, а ты, да пиши куда хочешь с какими хочешь кодами, какие по смыслу чувствуешь подходят, так и пиши Есть категории, и стандартные коды, ответ 200 на все случаи жизни это детсад какой то. hVosttНервишки не шалят, у меня бомбит, Лед попробуй или мороженку. hVosttstenford, Вы это админам объясните, что вы в 400 будете бизнесовые кейсы засовывать. Потом объясните группе тестирования что им надо ещё коды ошибок протокола тестировать. А потом, когда попросят прислать вместо вам адекватного разработчика, пожалуйтесь про нагугленный опыт. Разумеется, конечно если уровень тестировщикав выше плинтуса, то они должны понимать коды ошибок. Так же E2E тесты первым делом, обязательно проверяют коды респонса. Вижу ты от этого далек. hVosttЯ указываю на конкретные задачи и проблемы, от вас только неадекватные смешки Извени, кроме смеха твои проблемы и задачи ничего не вызывают. ) ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2018, 12:05 |
|
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
|
|||
---|---|---|---|
#18+
hVostt, Скажи про "402 Payment Required" платеж это бизнес логика или ошибка протокола?? ) ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2018, 12:10 |
|
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
|
|||
---|---|---|---|
#18+
skyANAМдааааа, развели срач... Что полезного-то в итоге? То, что пора звать модератора? Модератора-то за что? :)) ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2018, 12:12 |
|
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
|
|||
---|---|---|---|
#18+
ПарамонhVostt, Скажи про "402 Payment Required" платеж это бизнес логика или ошибка протокола?? ) Это код, который ни один нормальный разработчик использовать не будет. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2018, 12:14 |
|
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
|
|||
---|---|---|---|
#18+
ПарамонСкажи про "402 Payment Required" платеж это бизнес логика или ошибка протокола?? )Если забыл заплатить за протокол - то ошибка протокола )) ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2018, 12:15 |
|
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
|
|||
---|---|---|---|
#18+
Shocker.ProПарамонСкажи про "402 Payment Required" платеж это бизнес логика или ошибка протокола?? )Если забыл заплатить за протокол - то ошибка протокола )) ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2018, 12:16 |
|
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
|
|||
---|---|---|---|
#18+
hVostt, я уже все написал и аргументы что ты считаешь туфтой, как и я твои. все что я напишу дальше также будет подвержено критике и ты никогда не согласишься. вообщем я херачу 400 + тело, ты 200 + тело. мы все довольны. зачем писать только что мы тупые не пойму. почему бы не написать "я считаю так то и так ...". у меня больше кипит что ты всех налево и направо называешь тупыми и мы типо не читаем. я подчеркиваю я использую такой подход прочитав rfc, а не амазон, и считаю http часть приложения (rfc7231 это явно описывает прямо в начале текста) а значит протокол должен отражать ошибку явно. у меня все. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2018, 13:05 |
|
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
|
|||
---|---|---|---|
#18+
ПарамонРасписанно не все, а только основные принципы. Никогда сухое описание стандарта не обходит все кейсы, для более глубокого понимания обычно пишут книги, блоги и тд. Ты просто описываешь тут свое понимание, то есть непонимание, а копнуть глубже не в состоянии. Демагогия какая-то. Все-не все. RFC это стандарт. Давай книги приводи тогда, источники, если сам не в состоянии объяснить что ты делаешь и почему. Не проблема. ПарамонК примеру 5xx говорит о другом, 200 говорит "ОК". заметь, "ок, ты ошибся" - звучит глупо ОК говорит, что запрос успешно принят и обработан. Всё. Он не говорит о том, что у клиента есть деньги на счету для оплаты заказа, а если нет, он что получить должен? 400? 404? С логикой продолжаем не дружить? ПарамонЕсть категории, и стандартные коды, ответ 200 на все случаи жизни это детсад какой то. Ты пояснить можешь? Вижу, что пока не можешь. Чем тебя 200 ОК не устраивает для случаев, когда приложение возвращает ответ, который понял и обработан логикой. В чём проблемы? В внутри кода, ты тоже коды прокидываешь? Тебя прямо спрашивают, ты захрена запихал вот в этот ответ код 400? Ты что ответишь? Амазоном прикроешься? Не находишь, что это идиотия? ПарамонЛед попробуй или мороженку. Тролль из тебя унылый. ПарамонРазумеется, конечно если уровень тестировщикав выше плинтуса, то они должны понимать коды ошибок. Серьёзно? Ошибки 500 тестируете? Сколько кейсов на бэд реквест? Пихаете XML туда, где ожидаю JSON? Подаёте тысячу вариантов неправильного JSON? ПарамонИзвени, кроме смеха твои проблемы и задачи ничего не вызывают. ) Ну-ну. Ничего зазорного в том, что ты смеёшься, сидя в луже нет. Какие ещё дразнилки продемонстрируешь? ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2018, 13:50 |
|
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
|
|||
---|---|---|---|
#18+
ПарамонhVostt, Скажи про "402 Payment Required" платеж это бизнес логика или ошибка протокола?? ) Протокольный уровень. Универсальный код ошибки позволяет абстрагироваться от формата содержимого, и как в случае 403, бросить на экран/страницу оплаты, с точки зрения мониторинга тоже всё прозрачно. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2018, 13:53 |
|
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
|
|||
---|---|---|---|
#18+
handmadeFromRuя уже все написал и аргументы что ты считаешь туфтой, как и я твои. все что я напишу дальше также будет подвержено критике и ты никогда не согласишься. Какая-то демагогия. Я вам по существу с Парамоном, вы как всегда "о вечном". Ну и хрен с вами. handmadeFromRuвообщем я херачу 400 + тело, ты 200 + тело. мы все довольны. О чём тогда разговор? Кто-то опять форумом ошибся и думает, что это раздел моды, и типа надо делать как нравится, все фломастеры разные, а есть модные тенденции? Доволен? Счастлив за тебя. НАфига влез в дискуссию, если сам говоришь, что пофигу? handmadeFromRuзачем писать только что мы тупые не пойму. почему бы не написать "я считаю так то и так ...". у меня больше кипит что ты всех налево и направо называешь тупыми и мы типо не читаем. Ой, какие нежные. Вменяемых аргументов от вас не выпросишь, как рубль у еврея. А как что-то не так сказали в вашу сторону так разобиделись. Если проблема ток в этом, ок. Уж прастите, больше не буду handmadeFromRuя подчеркиваю я использую такой подход прочитав rfc, а не амазон, и считаю http часть приложения (rfc7231 это явно описывает прямо в начале текста) а значит протокол должен отражать ошибку явно. у меня все. В чем польза от того. что ты смешаешь свои сценарии с реальными ошибками протокола? ПРосто можешь пояснить? Или ограничишься "я считаю"? ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2018, 14:01 |
|
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
|
|||
---|---|---|---|
#18+
hVosttОК говорит, что запрос успешно принят и обработан. Всё. Он не говорит о том, что у клиента есть деньги на счету для оплаты заказа, а если нет, он что получить должен? 400? 404? Открой для себя новый код - 402 Payment Required. Да и вообще пройтись по статусам не помешает, а то выучил 200 и типа все, больше не нужно. А на все остальное говори так: AddxЭто код, который ни один нормальный разработчик использовать не будет. hVosttЧем тебя 200 ОК не устраивает для случаев, когда приложение возвращает ответ, который понял и обработан логикой . В чём проблемы? Тут могла быть ошибка, и тогда вменяемый сервис вернет 4xx. hVosttСерьёзно? Ошибки 500 тестируете? Сколько кейсов на бэд реквест? Пихаете XML туда, где ожидаю JSON? Подаёте тысячу вариантов неправильного JSON? Разумеется, тестируют максимум возможных кейсов от клиента, и возврат правельных статусов. 501 not implemented давольно частый случай, когда еще не весь функционал реализован и клиент должен об этом знать. Добро пожаловать в первый класс hVosttПротокольный уровень. Универсальный код ошибки позволяет абстрагироваться от формата содержимого, и как в случае 403, бросить на экран/страницу оплаты, с точки зрения мониторинга тоже всё прозрачно. Как уж на сковородке, все смеются уже. Просто скажи - оплата в твоем монимании это теперь уровень протокола и твой сервис вернет "200 + извините, вы не заплатали". )) Ты ведь так прямо и написал в преидущем посте. Ну или забыл заплатить за протокол, тогда 402 ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2018, 14:23 |
|
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
|
|||
---|---|---|---|
#18+
hVosttАмазоном прикроешься ps Как бы практика серьезных, мировых лидеров в этой области заслуживает внимания, в отличае от форумных Д’Артаньянов. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2018, 14:46 |
|
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
|
|||
---|---|---|---|
#18+
hVostt, я тебе уже объяснил что по последнему rcf http трактуют как протокол уровень приложения, так как это уровень приложения он должен показывать состояние, там четко написано что 400 это ошибки клиента и не важно какие. это прям написано в документе. аргумент прям из твоего же источника раз ты другое не воспринимаешь. вот мои аргументы из всех моих постов 1. на основе rfc http часть приложения а значит должно отражать его состояние в конкретный момент времени 2. я могу тестировать апи и понимать что запрос не прошел крайне просто 3. я не вижу проблемы для админов ну ответили мы 400 и? статистика по 400 ответам да нахера она мне нужна. статиска ошибок по логам в elk вот эт я понимаю что то серьезное и что и как и почему. 4. я не вижу проблемы для тестеров если они будут тестить ui так как не важно какой клиент он легко обработает без свистопляски вокруг а может там ошибка все таки вместо объекта по итогу я могу сказать одно.. делай как угодно. я изложил как я вижу ситуацию. твои аргументы меня не убедили, хотя ты считаешь их железными >Ой, какие нежные причем тут нежные? мне не нравиться общаться с человеком который считает нормальным через слово говорить оппоненту что он дурак. хвост я за время дисскусии с тобой ни разу не посмел тебя назвать дураком или еще что то, так почему ты позволяешь себе это? твоя же аргументация ..лалалалал дебилы..лалалалла да вы упоротные...лалалалала головой не думают (текст приблизительный но суть отражает) ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2018, 16:13 |
|
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
|
|||
---|---|---|---|
#18+
handmadeFromRu, 404 - это ошибка протокола (неверный адрес) или ошибка на уровне бизнес-логики (адрес правильный, но данных нет)? ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2018, 16:18 |
|
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
|
|||
---|---|---|---|
#18+
AddxhandmadeFromRu, 404 - это ошибка протокола (неверный адрес) или ошибка на уровне бизнес-логики (адрес правильный, но данных нет)? а может мы почитаем rfc что хвост нам упорно задвигает а ? 6.5.4. 404 Not Found The 404 (Not Found) status code indicates that the origin server did not find a current representation for the target resource or is not willing to disclose that one exists. A 404 status code does not indicate whether this lack of representation is temporary or permanent; the 410 (Gone) status code is preferred over 404 if the origin server knows, presumably through some configurable means, that the condition is likely to be permanent. где тут написано неверный адрес конкретно? тут где то написано что мы должны понимать по ресурсом? а теперь берем старый ответ 10.4.5 404 Not Found The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent я еще раз говорю вы почитай разные редакции rfc...прослеживает четкое изменение. раньше было жестко да щас изза сплошного спа и реста уже не так ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2018, 16:34 |
|
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
|
|||
---|---|---|---|
#18+
hVostt, rfc 2616 10.4.1 400 Bad Request The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications. rfc7231 6.5.1. 400 Bad Request The 400 (Bad Request) status code indicates that the server cannot or will not process the request due to something that is perceived to be a client error ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2018, 16:40 |
|
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
|
|||
---|---|---|---|
#18+
AddxhandmadeFromRu, 404 - это ошибка протокола (неверный адрес) или ошибка на уровне бизнес-логики (адрес правильный, но данных нет)? Ты ветку читаешь вообще? Ссылку на примеры от MS открыть в состоянии или их сюда перепечатать? ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2018, 16:45 |
|
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
|
|||
---|---|---|---|
#18+
handmadeFromRu, тут уже начали говорить "по понятиям", а не по RFC. А именно о "практике мировых лидеров". ))) Уж определитесь тогда, что берете за основу. Я, собственно, конкретный вопрос задал. Что вернется в одном, и что в другом случае? ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2018, 16:54 |
|
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
|
|||
---|---|---|---|
#18+
Addx, я хз кто там по понятиям но я пытаюсь вести диалог в человеческом русле. за основу беру то на что хвост меня и направил а именно современный стандарт rfc. и он стал гибче напорядок. я ответил текстом текущего стандарта и как было. если делать по текущему стандарту rfc то будет 404. и заметь - это не мое желание это стандарт. лет 5 назад я б сказал что хвост все правильно говорит, но и стандарт был другим раньше, щас он стал гибче. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2018, 17:04 |
|
|
start [/forum/topic.php?fid=18&msg=39715454&tid=1355117]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
69ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
66ms |
get tp. blocked users: |
2ms |
others: | 274ms |
total: | 457ms |
0 / 0 |