|
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
|
|||
---|---|---|---|
#18+
Проблема в том, что оборачивание в OperationResult вместе с сапрессингом ошибок и закатывание их в какой-то формат JSON приводит к тому, что все элементы инфраструктуры поставки, развёртывания и мониторинга придётся "научить" какому-то неведомому формату ошибок (а обычно это очередное больное воображение программистов). Это приводит к проблемам в больших проектах. К большим проблемам. А ещё становится весьма чувствительным развитие системы и доработки, которые могут расширять или изменять форматы сообщений внутри JSON, что доставляет много боли всем. В общем это дичь. Я ничего хорошего по этому поводу сказать не могу. Есть ошибки логики, есть ошибки приложения и как следствие ошибки веб. Есть ошибки сервера приложений. Всё это не просто так придумали и стандартизовали. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.10.2018, 12:23 |
|
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
|
|||
---|---|---|---|
#18+
CalabongaТяжело судить, что и почему вы там выпиливали, но могу со всей ответственностью заявить, что никогда не было проблем! Только профит! И на UI и на Backend. Серьёзно? Не верю. Все фронтендщики с опытом и знаниями как один скажут, что 200 ОК на все случаи жизни это полнейший шит. Уж извините. Админы скажут, вы ??*№Ц; издеваетесь?.. Как это адекватно мониторить ? И т.д. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.10.2018, 12:24 |
|
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
|
|||
---|---|---|---|
#18+
Видимо, у меня в моей статье не получилось донести до достопачтенной публики причину, почему я сделал OperationResult. Хотя существует вероятность, что никто и не читал статью, прежде чем начинать полемику. Если в кратце, то никакие HTTP статусы я не "проглатываю", а только дополняю некоторые из них дополнительной информацией. То есть я не только возвращаю BadRequest, но еще и говорю "ПОЧЕМУ"... Это "вкратце"... или около того... :) ... |
|||
:
Нравится:
Не нравится:
|
|||
03.10.2018, 12:28 |
|
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
|
|||
---|---|---|---|
#18+
Calabonga, ну ты сам говорил что ошибки возвращаешь обернутые в 200. ты уже определись если пишешь что и бедреквест также шлешь. потому что это противоречит тому что ты говорил в начале и также в твоей ссылке написано: Сервер должен всегда возвращать один код ответа как результат обработки запроса. Это код 200. А всю дополнительную информацию требуется передавать в теле ответа. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.10.2018, 13:18 |
|
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
|
|||
---|---|---|---|
#18+
handmadeFromRu, Наверное имелось ввиду "образно". Т.е. все передается через 200, но формально там зашита ошибка. Поэтому получается, что передается "BadRequest + ДопИнфо с описание того, что там бэд то". Это моя догадка ) Но проверю свою интуицию. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.10.2018, 13:33 |
|
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
|
|||
---|---|---|---|
#18+
WaspNewCore, Вот это пугает: авторСервер должен всегда возвращать один код ответа как результат обработки запроса. Это код 200..... Остальное можно не читать))) ... |
|||
:
Нравится:
Не нравится:
|
|||
03.10.2018, 13:38 |
|
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
|
|||
---|---|---|---|
#18+
WaspNewCore, хм я видимо прочитал иначе. ок мой косяк ... |
|||
:
Нравится:
Не нравится:
|
|||
03.10.2018, 13:40 |
|
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
|
|||
---|---|---|---|
#18+
handmadeFromRuWaspNewCore, хм я видимо прочитал иначе. ок мой косяк Прочитано думаю верно. Вопрос в интерпретации. Я предложил свою интерпретацию. Но от автора узнает что он имел ввиду. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.10.2018, 13:42 |
|
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
|
|||
---|---|---|---|
#18+
CalabongaВидимо, у меня в моей статье не получилось донести до достопачтенной публики причину, почему я сделал OperationResult OperationResult это отличное решение, позволяющее решать задачи на топ уровне в функциональном стиле. но не стоит его переносить на уровень HTTP, как бы противоречие только здесь ... |
|||
:
Нравится:
Не нравится:
|
|||
03.10.2018, 14:36 |
|
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
|
|||
---|---|---|---|
#18+
handmadeFromRu Сервер должен всегда возвращать один код ответа как результат обработки запроса. Это код 200. А всю дополнительную информацию требуется передавать в теле ответа. Вот с этим категорически не согласен, по многим объективным причинам. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.10.2018, 14:37 |
|
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
|
|||
---|---|---|---|
#18+
Petro123Вот это пугает: авторСервер должен всегда возвращать один код ответа как результат обработки запроса. Это код 200..... Остальное можно не читать))) Это не пугает. Я видел как минимум 3 проекта, где подобное было записано в секцию "технический долг" и его требовалось устранить в короткие сроки. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.10.2018, 14:38 |
|
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
|
|||
---|---|---|---|
#18+
Я так и не понял как все таки нужно правильно в итоге. Какой код ошибки нужно вернуть в ситуации: попытка добавить юзера в группу по ID группы, но такой группы не нашлось. Или попытка добавить юзера с FIO, длиннее чем предусмотрено ? код 400 ? Но как передать описание проблемы, чтобы дать понять на фронт энд, юзеру, что проблема в длине ФИО ? ... |
|||
:
Нравится:
Не нравится:
|
|||
03.10.2018, 15:13 |
|
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
|
|||
---|---|---|---|
#18+
WaspNewCore, на первый вопрос Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.
на 2. если ты делаешь валидацию на основе аннотации то у ModelState узнаешь ошибки и заворачиваешь в ответе со статусом как надо Код: c# 1. 2. 3. 4. 5. 6. 7.
ну в если где то глубже в бизнес слое то снова выкидывает ошибку как в примере 1. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.10.2018, 15:29 |
|
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
|
|||
---|---|---|---|
#18+
handmadeFromRu, это пример прямолинейный,можно добавить красивости чтоб обработчик ошибок бизснес логики был по умолчанию на всех методах апи и не каждый раз его пропихивать но в общем такое направление имхо ... |
|||
:
Нравится:
Не нравится:
|
|||
03.10.2018, 15:33 |
|
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
|
|||
---|---|---|---|
#18+
WaspNewCoreЯ так и не понял как все таки нужно правильно в итоге. Какой код ошибки нужно вернуть в ситуации: попытка добавить юзера в группу по ID группы, но такой группы не нашлось. Или попытка добавить юзера с FIO, длиннее чем предусмотрено ? код 400 ? Но как передать описание проблемы, чтобы дать понять на фронт энд, юзеру, что проблема в длине ФИО ? Таких ошибок не должно быть, эти ошибки инициируются клиентом из за незнания метаинформации. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.10.2018, 16:14 |
|
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
|
|||
---|---|---|---|
#18+
ViPRosТаких ошибок не должно быть, эти ошибки инициируются клиентом из за незнания метаинформации. Ну и что теперь ? ) Не проверять такие ошибки, расчитывая на корректность данных от клиента ? Ню ню ) По моему в любых публичных методах обязаны быть проверки входных параметров. Проверки входных параметров можно не делать в приватных метода, если эти проверки гарантировано делаются там, откуда идет вызов (т.к. это код этого-же класса, и, теоретически, можно это обеспечить). Но для надежности лучше продублировать. Меньше вероятности, что проскочит ошибка, а на производительности сильно не скажется. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.10.2018, 17:01 |
|
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
|
|||
---|---|---|---|
#18+
ViPRosТаких ошибок не должно быть, эти ошибки инициируются клиентом из за незнания метаинформации. Ок. Преступности не должно быть. Преступность инициируется людьми из-за незнания ими законов. Сам-то понял, какую глупость сказал? )) ... |
|||
:
Нравится:
Не нравится:
|
|||
03.10.2018, 17:04 |
|
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
|
|||
---|---|---|---|
#18+
"Особенно полезно при взаимодействии слабосвязанных компонентов, например, когда получая результат NULL при выполнении метода Send в EmailService вы не будете знать что случилось и дополнительная информация в этому случае вам бы точно не помешала." Так умиляет это повсеместное вы/мы.. Кто не будет знать то? Пользователь получит красивый попап, который ему сообщить "не удалось бла-бла, попытайтесь позже", а в лог на беке уйдут 33 вложенных эксепшена, которые кто-то возможно когда-то и прочитает. "Не удалось бла-бла" - и есть то самое сообщение от сервера пользователю, которое попадёт в блок обработки ошибки (благодаря http коду, ага), и стандартно (для всех ошибок) обработается. А красивый попап - обслуживает в едином стиле все исключения от сервера, которые попадают в тот же блок обработки исключений, только уже на клиенте. Поверьте, этот подход можно и нужно использовать не только WebAPI, И это прямо в интернете же написано. (( Эх, бекендеры... ... |
|||
:
Нравится:
Не нравится:
|
|||
03.10.2018, 19:30 |
|
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
|
|||
---|---|---|---|
#18+
При использовании OperationResult мы можем легко обработать все варианты. При результате номер 1 мы можем показать сообщение... При результате номер 2, когда количество на складе 53 При результате номер 3 мы также имеем возможность А в результате номер 4 мы точно знаем, что сервис сломался Не приведи Господь изнутри столкнуться с такой системой. Calabonga , вы собеседования проводите? ... |
|||
:
Нравится:
Не нравится:
|
|||
03.10.2018, 19:35 |
|
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
|
|||
---|---|---|---|
#18+
hVosttViPRosТаких ошибок не должно быть, эти ошибки инициируются клиентом из за незнания метаинформации. Ок. Преступности не должно быть. Преступность инициируется людьми из-за незнания ими законов. Сам-то понял, какую глупость сказал? )) Сам ты глупый. Заставь клиента послать правильную информацию в правильный адресат. А то всех ящеров, роботов и т.д. в поликлинику - лечить (и так блин везде очереди). ... |
|||
:
Нравится:
Не нравится:
|
|||
03.10.2018, 19:48 |
|
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
|
|||
---|---|---|---|
#18+
ViPRoshVosttпропущено... Ок. Преступности не должно быть. Преступность инициируется людьми из-за незнания ими законов. Сам-то понял, какую глупость сказал? )) Сам ты глупый. Заставь клиента послать правильную информацию в правильный адресат. А то всех ящеров, роботов и т.д. в поликлинику - лечить (и так блин везде очереди). Когда сделаешь публичное веб приложение, тогда и будешь рассуждать. Ты бы видел какой объём трафика генерируется всякими ботами и какое говно они пытаются послать. Ошибок у него не должно быть, ну ну ... |
|||
:
Нравится:
Не нравится:
|
|||
03.10.2018, 21:18 |
|
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
|
|||
---|---|---|---|
#18+
ViPRosЗаставь клиента На клиента надейся, а сам не плошай ) ... |
|||
:
Нравится:
Не нравится:
|
|||
03.10.2018, 21:33 |
|
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
|
|||
---|---|---|---|
#18+
Объясните гуры и мне Запрос: если отработало, то 200 + данные, или 404, если данные не удалось вернуть (нет данных, кривой url) Команда: если отработало, то 200/201 + данные если есть ошибки бизнес логики, то ... если падает, то 500 (и пофиг почему, логируем на бэке) если кривой запрос, то 400 + ... правильно думаю? что тут вместо "..." по феншую? ... |
|||
:
Нравится:
Не нравится:
|
|||
03.10.2018, 22:38 |
|
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
|
|||
---|---|---|---|
#18+
если падает, то 500 (и пофиг почему, логируем на бэке) если кривой запрос, то 400 + ... это отдельно, это общее ... |
|||
:
Нравится:
Не нравится:
|
|||
03.10.2018, 22:40 |
|
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
|
|||
---|---|---|---|
#18+
love_bachОбъясните гуры и мне Запрос: если отработало, то 200 + данные, или 404, если данные не удалось вернуть (нет данных, кривой url) Команда: если отработало, то 200/201 + данные если есть ошибки бизнес логики, то ... если падает, то 500 (и пофиг почему, логируем на бэке) если кривой запрос, то 400 + ... правильно думаю? что тут вместо "..." по феншую? вот тут более менее удачное описание подхода к тому, какие ошибки надо использовать. хорошей практикой зарекомендовало в случае бизнес ошибки возвращать код 400, формат ответа json и в body ответа писать json в твоем формате - например твой код ошибки, описание или что еще потребуется ... |
|||
:
Нравится:
Не нравится:
|
|||
04.10.2018, 09:24 |
|
|
start [/forum/topic.php?fid=18&msg=39712712&tid=1355117]: |
0ms |
get settings: |
11ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
71ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
51ms |
get tp. blocked users: |
1ms |
others: | 15ms |
total: | 182ms |
0 / 0 |