Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / ASP.NET Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3 4 5 6 7 8 9 10 .. 15   вперед  Ctrl
 Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?  [new]
WaspNewCore
Member

Откуда:
Сообщений: 55
Подскажите какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках/ коды ошибок.

Т.е. Не все же решается Http кодами. Не отвечать же на все запросы кодом 400 (Bad Request).
Как сообщить клиенту, что что-то идет не так. Речь не об ошибке 500. А о том, чтобы сообщить пользователю что он что-то не корректно ввел и т.д.

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

Как правильно ?
1 окт 18, 12:35    [21690993]     Ответить | Цитировать Сообщить модератору
 Re: Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?  [new]
hVostt
Member

Откуда:
Сообщений: 14762
WaspNewCore,

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

Никакого "кода ошибки" при этом не должно быть. Механизм валидации это отдельная песня. Стандартного механизма здесь нет.

В ASP.NET MVC в классическом исполнении можно использовать подход POST-REDIRECT-GET. В случае неправильного ввода, пользователь получает обратно форму, где соответствующие поля сопровождаются сообщениями об ошибке ввода, и, например, подкрашиваются красным цветом.
1 окт 18, 12:42    [21691015]     Ответить | Цитировать Сообщить модератору
 Re: Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?  [new]
skyANA
Member

Откуда: Зеленоград
Сообщений: 25536
WaspNewCore
Как сообщить клиенту, что что-то идет не так. Речь не об ошибке 500. А о том, чтобы сообщить пользователю что он что-то не корректно ввел и т.д.

Кто есть пользователь и что конкретно он ввёл? Дайте нормальный пример.

К примеру JavaScript-клиент передал в API левый JSON - это именно 400 Bad Request.
Передал левый идентификатор, по которому ничего не найдено - это 404 Not Found.
1 окт 18, 13:00    [21691069]     Ответить | Цитировать Сообщить модератору
 Re: Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?  [new]
WaspNewCore
Member

Откуда:
Сообщений: 55
Для примера смотрю как устроена у Яндекса.

https://tech.yandex.ru/pdd/doc/reference/email-ml-add-docpage/#emails-detailed
https://tech.yandex.ru/pdd/doc/reference/import-check-imports-docpage/#emails-detailed

У них сделано странно, на мой взгляд. Они вообще, похоже, отказались от Httpшных кодов ошибок. В том числе от ошибок 500 и от ошибок 401/403:

unknown — произошел временный сбой или ошибка работы API (повторите запрос позже).
no_token (no_domain, no_ip ) — не передан обязательный параметр.


И вот мне самому интересно. Как вообще сочетать Http коды ошибок, с некими внутренними кодами ошибок (те же коды 500 или 401).
1 окт 18, 13:08    [21691080]     Ответить | Цитировать Сообщить модератору
 Re: Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 34710
WaspNewCore
Как вообще сочетать Http коды ошибок, с некими внутренними кодами ошибок (те же коды 500 или 401).

HTTP ошибки это ошибки транспорта.
Вы их смешали с ошибками по бизнес логике ("Данный пользователь отсутствует").
Поэтому тема и вопрос - странный.
...
Как именно передавать ошибку от сервера клиенту - зависит от архитектуры проекта.
1 окт 18, 13:23    [21691107]     Ответить | Цитировать Сообщить модератору
 Re: Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?  [new]
WaspNewCore
Member

Откуда:
Сообщений: 55
Petro123
Как именно передавать ошибку от сервера клиенту - зависит от архитектуры проекта.


Ну вот я и спрашиваю же про практики. Чтобы выбрать.
1 окт 18, 13:32    [21691122]     Ответить | Цитировать Сообщить модератору
 Re: Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?  [new]
WaspNewCore
Member

Откуда:
Сообщений: 55
Petro123
Вы их смешали с ошибками по бизнес логике ("Данный пользователь отсутствует").


И вот тут кстати еще вопрос. Ошибка 404 (NotFound) применима к Web Api ?
Этот код стоит возвращать исключительно, если не найден некий url, или еще и в ситуации, если не найден искомый Юзер/Документ ?
1 окт 18, 13:35    [21691128]     Ответить | Цитировать Сообщить модератору
 Re: Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 34710
WaspNewCore
Petro123
Как именно передавать ошибку от сервера клиенту - зависит от архитектуры проекта.

Ну вот я и спрашиваю же про практики. Чтобы выбрать.

Пиши версию и архитектуру своего проекта. По всем вариантам никто обзор делать не будет.
1 окт 18, 13:40    [21691140]     Ответить | Цитировать Сообщить модератору
 Re: Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 34710
WaspNewCore
Petro123
Вы их смешали с ошибками по бизнес логике ("Данный пользователь отсутствует").


И вот тут кстати еще вопрос. Ошибка 404 (NotFound) применима к Web Api ?
Этот код стоит возвращать исключительно, если не найден некий url, или еще и в ситуации, если не найден искомый Юзер/Документ ?

Ошибки транспорта не пробрасываются наверх к юзверю.
Они остаются в системном коде внизу.
(Инкапсуляция, ООП)
1 окт 18, 13:41    [21691143]     Ответить | Цитировать Сообщить модератору
 Re: Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 34710
WaspNewCore,
Это юзверю после перехвата:
Картинка с другого сайта.
1 окт 18, 13:43    [21691147]     Ответить | Цитировать Сообщить модератору
 Re: Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?  [new]
skyANA
Member

Откуда: Зеленоград
Сообщений: 25536
Petro123
WaspNewCore
пропущено...


И вот тут кстати еще вопрос. Ошибка 404 (NotFound) применима к Web Api ?
Этот код стоит возвращать исключительно, если не найден некий url, или еще и в ситуации, если не найден искомый Юзер/Документ ?

Ошибки транспорта не пробрасываются наверх к юзверю.
Они остаются в системном коде внизу.
(Инкапсуляция, ООП)

Чего?

Пользователь запрашивает несуществующий ресурс, ему отдаётся 404 Not Found.
Пользователь запрашивает ресурс, к которому ему ограничен доступ, ему отдаётся 403 Forbidden.
1 окт 18, 13:48    [21691158]     Ответить | Цитировать Сообщить модератору
 Re: Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 34710
skyANA,
я к тебе обращался?
1 окт 18, 13:49    [21691163]     Ответить | Цитировать Сообщить модератору
 Re: Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?  [new]
WaspNewCore
Member

Откуда:
Сообщений: 55
Petro123
skyANA,
я к тебе обращался?


не но у меня же те же самые вопросы )

"И вот тут кстати еще вопрос. Ошибка 404 (NotFound) применима к Web Api ?
Этот код стоит возвращать исключительно, если не найден некий url, или еще и в ситуации, если не найден искомый Юзер/Документ ?"

тоже самое с ошибками 401/403.

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


Petro123
Пиши версию и архитектуру своего проекта. По всем вариантам никто обзор делать не будет.


Бэкэнд - Asp.net Core. Фронтэнд - Ангуляр. Rest подход.
Обычные бизнес задачки по ведению пользователей, их документов и прочего.
1 окт 18, 13:57    [21691183]     Ответить | Цитировать Сообщить модератору
 Re: Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 34710
WaspNewCore
не но у меня же те же самые вопросы )

ну дак вам я и отвечу. А с ним ответы всегда приводят к одному результату.

WaspNewCore
Ошибка 404 (NotFound) применима к Web Api ?

да. Т.к. это API, и если это API для рест.
Есть API для WCF, WinAPI32 и т.д. ))
1 окт 18, 14:02    [21691195]     Ответить | Цитировать Сообщить модератору
 Re: Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 34710
WaspNewCore
Бэкэнд - Asp.net Core. Фронтэнд - Ангуляр. Rest подход.
Обычные бизнес задачки по ведению пользователей, их документов и прочего.

В ангуляре бизнес логика, значит он всё перехватывает и выводит своё.
Ошибки типа "некорректный тип" не надо допускать вообще.
1 окт 18, 14:04    [21691203]     Ответить | Цитировать Сообщить модератору
 Re: Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?  [new]
WaspNewCore
Member

Откуда:
Сообщений: 55
ок. В общем думаю оставить коды 400, 401, 403, 500.

Но также нужно определится - в ситуации бизнес ошибки, какой код должен возвращаться ? 200 и в теле описании ошибки да ?
Правда не очень ясно, что делать с NotFound. Оставлять ли этот код или переносить в бизнес ошибки ? наверное лучше в бизнес ошибки - больше гибкости. Т.к. NotFound NotFound'у рознь: может при добавлении юзера не удалось записать его в указанный отдел, т.к. такого отдела нет. Или нет такого типа документа и т.д.
1 окт 18, 14:06    [21691210]     Ответить | Цитировать Сообщить модератору
 Re: Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 34710
WaspNewCore
оставить

что значит оставить?
У вас сам веб сервер отправит ошибку без вашего согласия.
Вы обязаны их обработать все на клиенте.
1 окт 18, 14:11    [21691235]     Ответить | Цитировать Сообщить модератору
 Re: Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 34710
WaspNewCore
NotFound NotFound'у рознь:

давайте конкретный пример с урлом по REST
1 окт 18, 14:12    [21691240]     Ответить | Цитировать Сообщить модератору
 Re: Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 34710
WaspNewCore,
Совет!
Изучайте совместно с кодом.
Давайте ангуляр, и вывод скрина что я дал по ошибке 404.
А потом продолжим.
Или вы не программист а постановщик?
1 окт 18, 14:15    [21691248]     Ответить | Цитировать Сообщить модератору
 Re: Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?  [new]
WaspNewCore
Member

Откуда:
Сообщений: 55
Petro123,

Я программист бэкэнда. Фронтэндер другой программист.
Моя задача предоставить удобный API.

Оставить коды - я имел ввиду, что можно по подобию яндекса завернуть все http-шные коды в коды приложения. Вон у них код ошибки "unknown — произошел временный сбой или ошибка работы API (повторите запрос позже)." Явно смахивает на завернутую ошибку 500.

И я еще не нашел у них в доке пример того, как обрабатываются ошибки 401/403. Могу предположить, что это у них может быть обернуто в бизнес ошибку. Есть некая ошибка "no_token (no_domain, no_ip ) — не передан обязательный параметр." но это речь об обязательных параметрах.
1 окт 18, 14:26    [21691276]     Ответить | Цитировать Сообщить модератору
 Re: Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?  [new]
WaspNewCore
Member

Откуда:
Сообщений: 55
Пример запроса:

HttpGet
api/customers/7
1 окт 18, 14:27    [21691278]     Ответить | Цитировать Сообщить модератору
 Re: Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 34710
WaspNewCore
по подобию яндекса завернуть все http-шные коды в коды приложения

Нет показаний к усложнению.
IMHO
"Сложнее всего в мире достигнуть простоты — это крайняя граница опыта и последнее усилие гения". © George Sand.

1 окт 18, 14:36    [21691293]     Ответить | Цитировать Сообщить модератору
 Re: Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?  [new]
skyANA
Member

Откуда: Зеленоград
Сообщений: 25536
Petro123
skyANA,
я к тебе обращался?
Ты пишешь на публичном форуме.
Хочешь приватной беседы, пиши ТСу на почту, в Скайп.
1 окт 18, 15:35    [21691386]     Ответить | Цитировать Сообщить модератору
 Re: Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?  [new]
skyANA
Member

Откуда: Зеленоград
Сообщений: 25536
Petro123
WaspNewCore
не но у меня же те же самые вопросы )

ну дак вам я и отвечу. А с ним ответы всегда приводят к одному результату.

Ага, спасибо мне автор топика говорит
1 окт 18, 15:36    [21691390]     Ответить | Цитировать Сообщить модератору
 Re: Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?  [new]
skyANA
Member

Откуда: Зеленоград
Сообщений: 25536
WaspNewCore
Petro123,

Я программист бэкэнда. Фронтэндер другой программист.
Моя задача предоставить удобный API.

Оставить коды - я имел ввиду, что можно по подобию яндекса завернуть все http-шные коды в коды приложения. Вон у них код ошибки "unknown — произошел временный сбой или ошибка работы API (повторите запрос позже)." Явно смахивает на завернутую ошибку 500.

И я еще не нашел у них в доке пример того, как обрабатываются ошибки 401/403. Могу предположить, что это у них может быть обернуто в бизнес ошибку. Есть некая ошибка "no_token (no_domain, no_ip ) — не передан обязательный параметр." но это речь об обязательных параметрах.

500 Internal Server Error советую обрабатывать по возможности на сервере.
Это вообще хороший индикатор того, что у вас что-то в приложении поломалось.

Если после выкатки очередной версии пошёл вал 500-х, значит где-то у нас серъёзная проблема нарисовалась.
Но все ошибки оборачивать тоже не стоит, так вы их просто перестанете видеть.

Хотя возможно у вас там развитый мониторинг и логирование как у Яндекса?
1 окт 18, 15:39    [21691396]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3 4 5 6 7 8 9 10 .. 15   вперед  Ctrl
Все форумы / ASP.NET Ответить