ReSQL.ru
     
powered by simpleCommunicator - 2.0.51     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / ASP.NET [игнор отключен] [закрыт для гостей] / Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
370 сообщений из 370, показаны все 15 страниц
  все  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39710853
WaspNewCore
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
WaspNewCore
Гость
Подскажите какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках/ коды ошибок.

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

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

Как правильно ?
...
Рейтинг: 0 / 0
01.10.2018, 12:35
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39710863
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
WaspNewCore,

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

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

В ASP.NET MVC в классическом исполнении можно использовать подход POST-REDIRECT-GET . В случае неправильного ввода, пользователь получает обратно форму, где соответствующие поля сопровождаются сообщениями об ошибке ввода, и, например, подкрашиваются красным цветом.
...
Рейтинг: 0 / 0
01.10.2018, 12:42
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39710879
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
WaspNewCoreКак сообщить клиенту, что что-то идет не так. Речь не об ошибке 500. А о том, чтобы сообщить пользователю что он что-то не корректно ввел и т.д.
Кто есть пользователь и что конкретно он ввёл? Дайте нормальный пример.

К примеру JavaScript-клиент передал в API левый JSON - это именно 400 Bad Request.
Передал левый идентификатор, по которому ничего не найдено - это 404 Not Found.
...
Рейтинг: 0 / 0
01.10.2018, 13:00
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39710881
WaspNewCore
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
WaspNewCore
Гость
Для примера смотрю как устроена у Яндекса.

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).
...
Рейтинг: 0 / 0
01.10.2018, 13:08
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39710891
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
WaspNewCoreКак вообще сочетать Http коды ошибок, с некими внутренними кодами ошибок (те же коды 500 или 401).
HTTP ошибки это ошибки транспорта.
Вы их смешали с ошибками по бизнес логике ("Данный пользователь отсутствует").
Поэтому тема и вопрос - странный.
...
Как именно передавать ошибку от сервера клиенту - зависит от архитектуры проекта.
...
Рейтинг: 0 / 0
01.10.2018, 13:23
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39710900
WaspNewCore
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
WaspNewCore
Гость
Petro123Как именно передавать ошибку от сервера клиенту - зависит от архитектуры проекта.

Ну вот я и спрашиваю же про практики. Чтобы выбрать.
...
Рейтинг: 0 / 0
01.10.2018, 13:32
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39710902
WaspNewCore
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
WaspNewCore
Гость
Petro123Вы их смешали с ошибками по бизнес логике ("Данный пользователь отсутствует").


И вот тут кстати еще вопрос. Ошибка 404 (NotFound) применима к Web Api ?
Этот код стоит возвращать исключительно, если не найден некий url, или еще и в ситуации, если не найден искомый Юзер/Документ ?
...
Рейтинг: 0 / 0
01.10.2018, 13:35
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39710905
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
WaspNewCorePetro123Как именно передавать ошибку от сервера клиенту - зависит от архитектуры проекта.
Ну вот я и спрашиваю же про практики. Чтобы выбрать.
Пиши версию и архитектуру своего проекта. По всем вариантам никто обзор делать не будет.
...
Рейтинг: 0 / 0
01.10.2018, 13:40
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39710906
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
WaspNewCorePetro123Вы их смешали с ошибками по бизнес логике ("Данный пользователь отсутствует").


И вот тут кстати еще вопрос. Ошибка 404 (NotFound) применима к Web Api ?
Этот код стоит возвращать исключительно, если не найден некий url, или еще и в ситуации, если не найден искомый Юзер/Документ ?
Ошибки транспорта не пробрасываются наверх к юзверю.
Они остаются в системном коде внизу.
(Инкапсуляция, ООП)
...
Рейтинг: 0 / 0
01.10.2018, 13:41
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39710908
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
WaspNewCore,
Это юзверю после перехвата:
...
Рейтинг: 0 / 0
01.10.2018, 13:43
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39710911
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
Petro123WaspNewCoreпропущено...


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

Пользователь запрашивает несуществующий ресурс, ему отдаётся 404 Not Found.
Пользователь запрашивает ресурс, к которому ему ограничен доступ, ему отдаётся 403 Forbidden.
...
Рейтинг: 0 / 0
01.10.2018, 13:48
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39710914
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
skyANA,
я к тебе обращался?
...
Рейтинг: 0 / 0
01.10.2018, 13:49
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39710917
WaspNewCore
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
WaspNewCore
Гость
Petro123skyANA,
я к тебе обращался?

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

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

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

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


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

Бэкэнд - Asp.net Core. Фронтэнд - Ангуляр. Rest подход.
Обычные бизнес задачки по ведению пользователей, их документов и прочего.
...
Рейтинг: 0 / 0
01.10.2018, 13:57
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39710920
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
WaspNewCoreне но у меня же те же самые вопросы )
ну дак вам я и отвечу. А с ним ответы всегда приводят к одному результату.

WaspNewCoreОшибка 404 (NotFound) применима к Web Api ?
да. Т.к. это API, и если это API для рест.
Есть API для WCF, WinAPI32 и т.д. ))
...
Рейтинг: 0 / 0
01.10.2018, 14:02
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39710922
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
WaspNewCoreБэкэнд - Asp.net Core. Фронтэнд - Ангуляр. Rest подход.
Обычные бизнес задачки по ведению пользователей, их документов и прочего.
В ангуляре бизнес логика, значит он всё перехватывает и выводит своё.
Ошибки типа "некорректный тип" не надо допускать вообще.
...
Рейтинг: 0 / 0
01.10.2018, 14:04
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39710926
WaspNewCore
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
WaspNewCore
Гость
ок. В общем думаю оставить коды 400, 401, 403, 500.

Но также нужно определится - в ситуации бизнес ошибки, какой код должен возвращаться ? 200 и в теле описании ошибки да ?
Правда не очень ясно, что делать с NotFound. Оставлять ли этот код или переносить в бизнес ошибки ? наверное лучше в бизнес ошибки - больше гибкости. Т.к. NotFound NotFound'у рознь: может при добавлении юзера не удалось записать его в указанный отдел, т.к. такого отдела нет. Или нет такого типа документа и т.д.
...
Рейтинг: 0 / 0
01.10.2018, 14:06
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39710931
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
WaspNewCoreоставить
что значит оставить?
У вас сам веб сервер отправит ошибку без вашего согласия.
Вы обязаны их обработать все на клиенте.
...
Рейтинг: 0 / 0
01.10.2018, 14:11
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39710934
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
WaspNewCoreNotFound NotFound'у рознь:
давайте конкретный пример с урлом по REST
...
Рейтинг: 0 / 0
01.10.2018, 14:12
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39710936
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
WaspNewCore,
Совет!
Изучайте совместно с кодом.
Давайте ангуляр, и вывод скрина что я дал по ошибке 404.
А потом продолжим.
Или вы не программист а постановщик?
...
Рейтинг: 0 / 0
01.10.2018, 14:15
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39710947
WaspNewCore
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
WaspNewCore
Гость
Petro123,

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

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

И я еще не нашел у них в доке пример того, как обрабатываются ошибки 401/403. Могу предположить, что это у них может быть обернуто в бизнес ошибку. Есть некая ошибка "no_token (no_domain, no_ip ) — не передан обязательный параметр." но это речь об обязательных параметрах.
...
Рейтинг: 0 / 0
01.10.2018, 14:26
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39710948
WaspNewCore
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
WaspNewCore
Гость
Пример запроса:

Код: c#
1.
2.
HttpGet
api/customers/7
...
Рейтинг: 0 / 0
01.10.2018, 14:27
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39710952
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
WaspNewCoreпо подобию яндекса завернуть все http-шные коды в коды приложения
Нет показаний к усложнению.
IMHO
"Сложнее всего в мире достигнуть простоты — это крайняя граница опыта и последнее усилие гения". © George Sand.
...
Рейтинг: 0 / 0
01.10.2018, 14:36
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39710985
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
Petro123skyANA,
я к тебе обращался?Ты пишешь на публичном форуме.
Хочешь приватной беседы, пиши ТСу на почту, в Скайп.
...
Рейтинг: 0 / 0
01.10.2018, 15:35
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39710988
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
Petro123WaspNewCoreне но у меня же те же самые вопросы )
ну дак вам я и отвечу. А с ним ответы всегда приводят к одному результату.
Ага, спасибо мне автор топика говорит
...
Рейтинг: 0 / 0
01.10.2018, 15:36
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39710992
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
WaspNewCorePetro123,

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

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

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

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

Хотя возможно у вас там развитый мониторинг и логирование как у Яндекса?
...
Рейтинг: 0 / 0
01.10.2018, 15:39
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39710994
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
WaspNewCoreИ я еще не нашел у них в доке пример того, как обрабатываются ошибки 401/403. Могу предположить, что это у них может быть обернуто в бизнес ошибку. Есть некая ошибка "no_token (no_domain, no_ip ) — не передан обязательный параметр." но это речь об обязательных параметрах.А зачем Вам как у них? Как надо Вам?
...
Рейтинг: 0 / 0
01.10.2018, 15:40
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39711005
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
WaspNewCoreМоя задача предоставить удобный API.
Всё что можно обработать и вернуть адекватный ситуации Http code, то обрабатывайте.

WaspNewCoreПример запроса:
Код: c#
1.
2.
HttpGet
api/customers/7

Если есть такой кастомер, то 200, если нет, то 404 Not found.
Если пользователь не имеет права на получение данной информации, то 403 Forbidden.
Если api/customers/asda##$Vfg"DROP DATABASE" , то 400 Bad request.
...
Рейтинг: 0 / 0
01.10.2018, 15:44
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39711083
Calabonga
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Calabonga
Гость
WaspNewCore,

Я использую договоренность с нашими "бэкэндирами" - если не ошибка сервера (не 500), то всегда возвращают 200, а результате отправляю OperationResult, где есть Т - результат, Exception, + метадата...
...
Рейтинг: 0 / 0
01.10.2018, 16:52
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39711097
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
Calabongaесли не ошибка сервера (не 500), то всегда возвращают 200
т.е. вы все ошибки ниже заменили на 200?
авторWeb Server Status Codes And Messages

The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request. These codes are defined below. The Status Message is intended to give a short textual description of the Status-Code.

1xx: Informational - Request received, continuing process

2xx: Success - The action was successfully received, understood, and accepted

3xx: Redirection - Further action must be taken in order to complete the request

4xx: Client Error - The request contains bad syntax or cannot be fulfilled

5xx: Server Error - The server failed to fulfill an apparently valid request
...
Рейтинг: 0 / 0
01.10.2018, 17:16
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39711098
Calabonga
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Calabonga
Гость
Calabonga,

Забыл ссылку вставить OperationResult
...
Рейтинг: 0 / 0
01.10.2018, 17:18
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39711099
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
Calabonga,
не особо вижу смысла, но если "договорились", то и океюшки)
...
Рейтинг: 0 / 0
01.10.2018, 17:18
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39711103
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
Calabonga OperationResult
авторЗаказ добавлен в корзину.
Презервативы закончились на складе.
В корзине уже есть такой товар.
Нет ответа. Ошибка сервиса или сервис не доступен.

смешивание бизнес логики и системной по протоколу
...
Рейтинг: 0 / 0
01.10.2018, 17:22
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39711376
stenford
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
stenford
Участник
WaspNewCore"И вот тут кстати еще вопрос. Ошибка 404 (NotFound) применима к Web Api ?
Этот код стоит возвращать исключительно, если не найден некий url, или еще и в ситуации, если не найден искомый Юзер/Документ ?"

да, применима, и именно так и надо делать. А бизнес ошибки лежат в немного другой плоскости, если надо обьяснить причину почему возвращен код 400 или 404, то ничто вам не мешает добавить json боди где описать все что требуется
...
Рейтинг: 0 / 0
02.10.2018, 02:26
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39711405
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
WaspNewCoreИ вот мне самому интересно. Как вообще сочетать Http коды ошибок, с некими внутренними кодами ошибок (те же коды 500 или 401).

Ваша проблема здесь.

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

Яндекс в приведённом вами примере не отказался от этого. Есть внутренняя логика, когда у них в теле ответа success: false, это не ошибка в понимании HTTP и работы приложения. Это ответ логики.

Представим себе онлайн калькулятор. Отправляем два числа, получаем результат деления. Если отправим, допустим, 1 и 0, то по-вашему что должно вернуться? Код ошибки 500? Сервер упал, когда пытался разделить на ноль? Ответ очевиден. (нет конечно же!!)

Насчёт 404. Если вы делаете запрос типа GET: /api/documents/4
А документа с id=4 нет, то вы возвращаете 404, потому что это ошибка именно HTTP такого класса.
Это не 200 OK с телом, в котором написано, что документа 4 нет.
Почему?
Потому что речь идёт об URL, такого URL действительно нет, и с точки зрения HTTP монопенисуально почему (документа нет, это пофигу чего там нет).

Разберитесь с терминологией. Тогда всё станет очевидно и понятно.
...
Рейтинг: 0 / 0
02.10.2018, 07:39
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39711428
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
CalabongaWaspNewCore,

Я использую договоренность с нашими "бэкэндирами" - если не ошибка сервера (не 500), то всегда возвращают 200, а результате отправляю OperationResult, где есть Т - результат, Exception, + метадата...
И как вы это дело мониторите? Какой процент реальных 200, а какой ошибок, завернутых в 200?
...
Рейтинг: 0 / 0
02.10.2018, 08:45
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39711502
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
skyANA,

Некоторые путают RPC и REST и можно увидеть смешение, это результат того, что как в голове.
Отсюда ошибки, завёрнутые в 200 и проблемы с мониторингом.
...
Рейтинг: 0 / 0
02.10.2018, 10:41
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39711503
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
hVosttэто результат того, что как в голове.

*каша в голове
...
Рейтинг: 0 / 0
02.10.2018, 10:41
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39711549
love_bach
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
love_bach
Участник
hVosttНасчёт 404. Если вы делаете запрос типа GET: /api/documents/4
А документа с id=4 нет, то вы возвращаете 404, потому что это ошибка именно HTTP такого класса

а почему не 204 (204 No Content - "сервер успешно обработал запрос, но в ответе были переданы только заголовки без тела сообщения")?
ведь есть разница
GET: /api/documents/4 (такой url есть, он обрабатывается логикой приложения)
и
GET: /api/d a cuments/4 (а такого url нет вообще)
...
Рейтинг: 0 / 0
02.10.2018, 11:51
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39711559
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
love_bachGET: /api/documents/4 (такой url есть, он обрабатывается логикой приложения)
и
GET: /api/d a cuments/4 (а такого url нет вообще)

с точки зрения HTTP нет разницы, это нужно понимать.

что опечатка, что неправильный идентификатор -- это 404, по многим причинам
...
Рейтинг: 0 / 0
02.10.2018, 12:06
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39711645
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
love_bachа почему не 204 (204 No Content - "сервер успешно обработал запрос, но в ответе были переданы только заголовки без тела сообщения")?

да, самый яркий пример, Heartbeat
...
Рейтинг: 0 / 0
02.10.2018, 13:41
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39712117
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
Если посмотри к примеру описания ошибок по этой ссылке, то можно понять, что статус ошибки имеет прямое отношение к бизнес логике приложения.

Common REST API Error Codes
...
Рейтинг: 0 / 0
02.10.2018, 22:19
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39712178
Calabonga
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Calabonga
Гость
Petro123Calabonga OperationResult
авторЗаказ добавлен в корзину.
Презервативы закончились на складе.
В корзине уже есть такой товар.
Нет ответа. Ошибка сервиса или сервис не доступен.

смешивание бизнес логики и системной по протоколу

Никакого смешивания при моём подходет - нет! Объясню ниже и по пунктам. А что касается выдачи системых ошибок "наружу" - это еще тот вопрос. Более того, наоборот, загружать пользователя ошибками и бизнес-логики, и системы, в принципе не имеет смысла! Информация о системных ошибках (например, 500) никоим образом не сделают счастливым их получателей. Поэтому я и не смешиваю ошибки протокола HTTP и бизнес-логики. То есть если сервис работает - всегда 200, а если нет, то это уже другая история и тут OperationResult не поможет. И опять же, для ошибок бизнес-логики при использовании OpertionResult (или любой другой "обертки") у меня есть возможность более информативно описать случай бизнес-логики на сервере.

Теперь про "смешивание"
Ну, во-первых. В том-то и дело, что ошибки системы для конечного пользователя не нужны (я говорю например про SPA), а ошибки "user friendly" - это работает "на УРА". Мы их просто "пробрасываем" до пользователя исключая бизнес-логику по их обработке на стороне клиента.

Во-вторых, когда случается "Ошибка сервиса или сервис не доступен.", тогда OperationResult не может быть результатом ответа по опледелению. То есть при таких ошибках OpertionResult не работает. :)

В-третьих, если API работает для внешних сайтов (сторонние пользователи API, не наш GUI), то для них просто в свойство Exception у OperationResult "идут/не идут" (путём включения "галки" в настройках) системные ошибки, вернее сказать, не "системые", а "ошибки более низкого уровня".

В-четвертых, при использовании OperationResult написание unit-тестов для меня существенно упрощается.

В любом случае, данная практика отточена на протяжении более 10 лет использования.
И, кстати, OperationResult позволяет максимально близко реализовать принципы описанные здесь
...
Рейтинг: 0 / 0
03.10.2018, 04:00
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39712260
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
CalabongaPetro123пропущено...

пропущено...

смешивание бизнес логики и системной по протоколу

Никакого смешивания при моём подходет - нет! Объясню ниже и по пунктам. А что касается выдачи системых ошибок "наружу" - это еще тот вопрос. Более того, наоборот, загружать пользователя ошибками и бизнес-логики, и системы, в принципе не имеет смысла! Информация о системных ошибках (например, 500) никоим образом не сделают счастливым их получателей. Поэтому я и не смешиваю ошибки протокола HTTP и бизнес-логики. То есть если сервис работает - всегда 200, а если нет, то это уже другая история и тут OperationResult не поможет. И опять же, для ошибок бизнес-логики при использовании OpertionResult (или любой другой "обертки") у меня есть возможность более информативно описать случай бизнес-логики на сервере.

Теперь про "смешивание"
Ну, во-первых. В том-то и дело, что ошибки системы для конечного пользователя не нужны (я говорю например про SPA), а ошибки "user friendly" - это работает "на УРА". Мы их просто "пробрасываем" до пользователя исключая бизнес-логику по их обработке на стороне клиента.

Во-вторых, когда случается "Ошибка сервиса или сервис не доступен.", тогда OperationResult не может быть результатом ответа по опледелению. То есть при таких ошибках OpertionResult не работает. :)

В-третьих, если API работает для внешних сайтов (сторонние пользователи API, не наш GUI), то для них просто в свойство Exception у OperationResult "идут/не идут" (путём включения "галки" в настройках) системные ошибки, вернее сказать, не "системые", а "ошибки более низкого уровня".

В-четвертых, при использовании OperationResult написание unit-тестов для меня существенно упрощается.

В любом случае, данная практика отточена на протяжении более 10 лет использования.
И, кстати, OperationResult позволяет максимально близко реализовать принципы описанные здесь
Так и в чём профит-то, кроме тестов?
...
Рейтинг: 0 / 0
03.10.2018, 10:01
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39712280
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
Calabonga,

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

В общем, в одном доставшемся нам проекте мы выпиливали "гениальные" обёртки всего и вся в 200.
Потому что страдали все.

Строго не рекомендую подобный подход.
...
Рейтинг: 0 / 0
03.10.2018, 10:42
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39712281
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
CalabongaВ-четвертых, при использовании OperationResult написание unit-тестов для меня существенно упрощается.

Здесь вообще непонятно, в чём упрощение.
...
Рейтинг: 0 / 0
03.10.2018, 10:43
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39712302
handmadeFromRu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
handmadeFromRu
Участник
оо вставлю свои 5 копеек.
у нас на работе как раз такой батл периодически делается. люди по разному обработку делают так как команды разные и мало контактируют. я делает со статусами http по многим причинам. к примеру на js я в отдельном блоке отловлю эту ситуацию, в коде c# у меня вылетит ошибка и я пойму что пошло что то не так. когда же оборачивают в OperationResult то мне надо предугадывать(не помню название стороних сервисов - там подменяли на 200 ответ возвращаемую сущность без всяких флагов) или проверять поле флаг все ок ли.
Вообщем механизм статусов http имхо эт как прокидывание ошибок из кишок библы ест и надо использовать а не тупо проглатывать.
...
Рейтинг: 0 / 0
03.10.2018, 11:11
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39712328
Дмитрий Мух
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дмитрий Мух
Участник
handmadeFromRuВообщем механизм статусов http имхо эт как прокидывание ошибок из кишок библы ест и надо использовать а не тупо проглатывать.
А можешь перефразировать? Не понятно.
...
Рейтинг: 0 / 0
03.10.2018, 11:51
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39712346
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
ПарамонЕсли посмотри к примеру описания ошибок по этой ссылке, то можно понять, что статус ошибки имеет прямое отношение к бизнес логике приложения.

Common REST API Error Codes что то там намешано на одну ошибку кучу всего.
Не понял как это практически все использовать.
...
Рейтинг: 0 / 0
03.10.2018, 12:11
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39712353
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
hVostt, handmadeFromRu, +1,
А оборачивание кода ошибки в ResultXX... уже обсуждали в отдельной теме.
...
Рейтинг: 0 / 0
03.10.2018, 12:15
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39712360
Calabonga
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Calabonga
Гость
hVosttCalabonga,

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

В общем, в одном доставшемся нам проекте мы выпиливали "гениальные" обёртки всего и вся в 200.
Потому что страдали все.

Строго не рекомендую подобный подход.

Тяжело судить, что и почему вы там выпиливали, но могу со всей ответственностью заявить, что никогда не было проблем! Только профит! И на UI и на Backend.
...
Рейтинг: 0 / 0
03.10.2018, 12:20
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39712361
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
Проблема в том, что оборачивание в OperationResult вместе с сапрессингом ошибок и закатывание их в какой-то формат JSON приводит к тому, что все элементы инфраструктуры поставки, развёртывания и мониторинга придётся "научить" какому-то неведомому формату ошибок (а обычно это очередное больное воображение программистов). Это приводит к проблемам в больших проектах. К большим проблемам. А ещё становится весьма чувствительным развитие системы и доработки, которые могут расширять или изменять форматы сообщений внутри JSON, что доставляет много боли всем.

В общем это дичь. Я ничего хорошего по этому поводу сказать не могу.

Есть ошибки логики, есть ошибки приложения и как следствие ошибки веб. Есть ошибки сервера приложений. Всё это не просто так придумали и стандартизовали.
...
Рейтинг: 0 / 0
03.10.2018, 12:23
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39712362
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
CalabongaТяжело судить, что и почему вы там выпиливали, но могу со всей ответственностью заявить, что никогда не было проблем! Только профит! И на UI и на Backend.

Серьёзно? Не верю. Все фронтендщики с опытом и знаниями как один скажут, что 200 ОК на все случаи жизни это полнейший шит. Уж извините.

Админы скажут, вы ??*№Ц; издеваетесь?.. Как это адекватно мониторить ?

И т.д.
...
Рейтинг: 0 / 0
03.10.2018, 12:24
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39712365
Calabonga
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Calabonga
Гость
Видимо, у меня в моей статье не получилось донести до достопачтенной публики причину, почему я сделал OperationResult. Хотя существует вероятность, что никто и не читал статью, прежде чем начинать полемику.

Если в кратце, то никакие HTTP статусы я не "проглатываю", а только дополняю некоторые из них дополнительной информацией. То есть я не только возвращаю BadRequest, но еще и говорю "ПОЧЕМУ"... Это "вкратце"... или около того... :)
...
Рейтинг: 0 / 0
03.10.2018, 12:28
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39712392
handmadeFromRu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
handmadeFromRu
Участник
Calabonga,
ну ты сам говорил что ошибки возвращаешь обернутые в 200. ты уже определись если пишешь что и бедреквест также шлешь.
потому что это противоречит тому что ты говорил в начале и также в твоей ссылке написано:

Сервер должен всегда возвращать один код ответа как результат обработки запроса. Это код 200. А всю дополнительную информацию требуется передавать в теле ответа.
...
Рейтинг: 0 / 0
03.10.2018, 13:18
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39712413
WaspNewCore
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
WaspNewCore
Гость
handmadeFromRu,

Наверное имелось ввиду "образно". Т.е. все передается через 200, но формально там зашита ошибка. Поэтому получается, что передается "BadRequest + ДопИнфо с описание того, что там бэд то".

Это моя догадка ) Но проверю свою интуицию.
...
Рейтинг: 0 / 0
03.10.2018, 13:33
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39712419
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
WaspNewCore,

Вот это пугает:
авторСервер должен всегда возвращать один код ответа как результат обработки запроса. Это код 200.....
Остальное можно не читать)))
...
Рейтинг: 0 / 0
03.10.2018, 13:38
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39712422
handmadeFromRu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
handmadeFromRu
Участник
WaspNewCore,

хм я видимо прочитал иначе. ок мой косяк
...
Рейтинг: 0 / 0
03.10.2018, 13:40
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39712423
WaspNewCore
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
WaspNewCore
Гость
handmadeFromRuWaspNewCore,

хм я видимо прочитал иначе. ок мой косяк

Прочитано думаю верно. Вопрос в интерпретации. Я предложил свою интерпретацию. Но от автора узнает что он имел ввиду.
...
Рейтинг: 0 / 0
03.10.2018, 13:42
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39712461
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
CalabongaВидимо, у меня в моей статье не получилось донести до достопачтенной публики причину, почему я сделал OperationResult

OperationResult это отличное решение, позволяющее решать задачи на топ уровне в функциональном стиле.
но не стоит его переносить на уровень HTTP, как бы противоречие только здесь
...
Рейтинг: 0 / 0
03.10.2018, 14:36
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39712463
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
handmadeFromRu Сервер должен всегда возвращать один код ответа как результат обработки запроса. Это код 200. А всю дополнительную информацию требуется передавать в теле ответа.

Вот с этим категорически не согласен, по многим объективным причинам.
...
Рейтинг: 0 / 0
03.10.2018, 14:37
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39712464
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
Petro123Вот это пугает:
авторСервер должен всегда возвращать один код ответа как результат обработки запроса. Это код 200.....
Остальное можно не читать)))

Это не пугает. Я видел как минимум 3 проекта, где подобное было записано в секцию "технический долг" и его требовалось устранить в короткие сроки.
...
Рейтинг: 0 / 0
03.10.2018, 14:38
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39712495
WaspNewCore
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
WaspNewCore
Гость
Я так и не понял как все таки нужно правильно в итоге.

Какой код ошибки нужно вернуть в ситуации: попытка добавить юзера в группу по ID группы, но такой группы не нашлось. Или попытка добавить юзера с FIO, длиннее чем предусмотрено ?

код 400 ? Но как передать описание проблемы, чтобы дать понять на фронт энд, юзеру, что проблема в длине ФИО ?
...
Рейтинг: 0 / 0
03.10.2018, 15:13
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39712506
handmadeFromRu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
handmadeFromRu
Участник
WaspNewCore,

на первый вопрос
Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
..
var useGroup = repo.get(byId);
if (userGroup== null) throw BusnessLogicException("ALRAM");
..

public JsouResult Action(model) {
 try{
var temp= doSome();
 return Json(temp);
}catch(BusnessLogicException e)
responce.status = 400;
Content(e.Message);
}



на 2. если ты делаешь валидацию на основе аннотации то у ModelState узнаешь ошибки и заворачиваешь в ответе со статусом как надо
Код: c#
1.
2.
3.
4.
5.
6.
7.
public JsouResult Action(model) {
if (ModelState.Valid){}
else {
responce.status = 400;
return Json (ModalStateErorToYour conten)
}
}


ну в если где то глубже в бизнес слое то снова выкидывает ошибку как в примере 1.
...
Рейтинг: 0 / 0
03.10.2018, 15:29
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39712511
handmadeFromRu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
handmadeFromRu
Участник
handmadeFromRu,

это пример прямолинейный,можно добавить красивости чтоб обработчик ошибок бизснес логики был по умолчанию на всех методах апи и не каждый раз его пропихивать но в общем такое направление имхо
...
Рейтинг: 0 / 0
03.10.2018, 15:33
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39712535
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ViPRos
Участник
WaspNewCoreЯ так и не понял как все таки нужно правильно в итоге.

Какой код ошибки нужно вернуть в ситуации: попытка добавить юзера в группу по ID группы, но такой группы не нашлось. Или попытка добавить юзера с FIO, длиннее чем предусмотрено ?

код 400 ? Но как передать описание проблемы, чтобы дать понять на фронт энд, юзеру, что проблема в длине ФИО ?
Таких ошибок не должно быть, эти ошибки инициируются клиентом из за незнания метаинформации.
...
Рейтинг: 0 / 0
03.10.2018, 16:14
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39712559
WaspNewCore
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
WaspNewCore
Гость
ViPRosТаких ошибок не должно быть, эти ошибки инициируются клиентом из за незнания метаинформации.

Ну и что теперь ? ) Не проверять такие ошибки, расчитывая на корректность данных от клиента ? Ню ню )

По моему в любых публичных методах обязаны быть проверки входных параметров.
Проверки входных параметров можно не делать в приватных метода, если эти проверки гарантировано делаются там, откуда идет вызов (т.к. это код этого-же класса, и, теоретически, можно это обеспечить). Но для надежности лучше продублировать. Меньше вероятности, что проскочит ошибка, а на производительности сильно не скажется.
...
Рейтинг: 0 / 0
03.10.2018, 17:01
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39712561
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
ViPRosТаких ошибок не должно быть, эти ошибки инициируются клиентом из за незнания метаинформации.

Ок. Преступности не должно быть. Преступность инициируется людьми из-за незнания ими законов.

Сам-то понял, какую глупость сказал? ))
...
Рейтинг: 0 / 0
03.10.2018, 17:04
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39712645
Агнец за бортом
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Агнец за бортом
Участник
"Особенно полезно при взаимодействии слабосвязанных компонентов, например, когда получая результат NULL при выполнении метода Send в EmailService вы не будете знать что случилось и дополнительная информация в этому случае вам бы точно не помешала."

Так умиляет это повсеместное вы/мы.. Кто не будет знать то? Пользователь получит красивый попап, который ему сообщить "не удалось бла-бла, попытайтесь позже", а в лог на беке уйдут 33 вложенных эксепшена, которые кто-то возможно когда-то и прочитает.

"Не удалось бла-бла" - и есть то самое сообщение от сервера пользователю, которое попадёт в блок обработки ошибки (благодаря http коду, ага), и стандартно (для всех ошибок) обработается.

А красивый попап - обслуживает в едином стиле все исключения от сервера, которые попадают в тот же блок обработки исключений, только уже на клиенте.

Поверьте, этот подход можно и нужно использовать не только WebAPI,
И это прямо в интернете же написано. (( Эх, бекендеры...
...
Рейтинг: 0 / 0
03.10.2018, 19:30
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39712648
Агнец за бортом
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Агнец за бортом
Участник
При использовании OperationResult мы можем легко обработать все варианты.
При результате номер 1 мы можем показать сообщение...
При результате номер 2, когда количество на складе 53
При результате номер 3 мы также имеем возможность
А в результате номер 4 мы точно знаем, что сервис сломался

Не приведи Господь изнутри столкнуться с такой системой.

Calabonga , вы собеседования проводите?
...
Рейтинг: 0 / 0
03.10.2018, 19:35
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39712655
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ViPRos
Участник
hVosttViPRosТаких ошибок не должно быть, эти ошибки инициируются клиентом из за незнания метаинформации.

Ок. Преступности не должно быть. Преступность инициируется людьми из-за незнания ими законов.

Сам-то понял, какую глупость сказал? ))
Сам ты глупый.
Заставь клиента послать правильную информацию в правильный адресат.
А то всех ящеров, роботов и т.д. в поликлинику - лечить (и так блин везде очереди).
...
Рейтинг: 0 / 0
03.10.2018, 19:48
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39712681
Дмитрий Мух
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дмитрий Мух
Участник
ViPRoshVosttпропущено...


Ок. Преступности не должно быть. Преступность инициируется людьми из-за незнания ими законов.

Сам-то понял, какую глупость сказал? ))
Сам ты глупый.
Заставь клиента послать правильную информацию в правильный адресат.
А то всех ящеров, роботов и т.д. в поликлинику - лечить (и так блин везде очереди).
Когда сделаешь публичное веб приложение, тогда и будешь рассуждать.
Ты бы видел какой объём трафика генерируется всякими ботами и какое говно они пытаются послать.

Ошибок у него не должно быть, ну ну
...
Рейтинг: 0 / 0
03.10.2018, 21:18
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39712687
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
ViPRosЗаставь клиента
На клиента надейся, а сам не плошай )
...
Рейтинг: 0 / 0
03.10.2018, 21:33
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39712711
love_bach
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
love_bach
Участник
Объясните гуры и мне

Запрос:
если отработало, то 200 + данные, или 404, если данные не удалось вернуть (нет данных, кривой url)

Команда:
если отработало, то 200/201 + данные
если есть ошибки бизнес логики, то ...
если падает, то 500 (и пофиг почему, логируем на бэке)
если кривой запрос, то 400 + ...

правильно думаю? что тут вместо "..." по феншую?
...
Рейтинг: 0 / 0
03.10.2018, 22:38
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39712712
love_bach
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
love_bach
Участник
если падает, то 500 (и пофиг почему, логируем на бэке)
если кривой запрос, то 400 + ...

это отдельно, это общее
...
Рейтинг: 0 / 0
03.10.2018, 22:40
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39712795
monstrU
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
monstrU
Участник
love_bachОбъясните гуры и мне

Запрос:
если отработало, то 200 + данные, или 404, если данные не удалось вернуть (нет данных, кривой url)

Команда:
если отработало, то 200/201 + данные
если есть ошибки бизнес логики, то ...
если падает, то 500 (и пофиг почему, логируем на бэке)
если кривой запрос, то 400 + ...

правильно думаю? что тут вместо "..." по феншую?

вот тут более менее удачное описание подхода к тому, какие ошибки надо использовать.
хорошей практикой зарекомендовало в случае бизнес ошибки возвращать код 400, формат ответа json и в body ответа писать json в твоем формате - например твой код ошибки, описание или что еще потребуется
...
Рейтинг: 0 / 0
04.10.2018, 09:24
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39712797
monstrU
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
monstrU
Участник
love_bach,

вот пример с микрософта

вот такой ответ ты должен возвращать на уровне http для бизнес ошибок - всем все будет понятно

Код: javascript
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
HTTP/1.1 400 Bad Request
Content-Type: application/json; charset=utf-8
Content-Length: 320

{
  "Message": "The request is invalid.",
  "ModelState": {
    "item": [
      "Required property 'Name' not found in JSON. Path '', line 1, position 14."
    ],
    "item.Name": [
      "The Name field is required."
    ],
    "item.Price": [
      "The field Price must be between 0 and 999."
    ]
  }
}
...
Рейтинг: 0 / 0
04.10.2018, 09:28
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39712798
love_bach
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
love_bach
Участник
monstrUlove_bach,

вот пример с микрософта

вот такой ответ ты должен возвращать на уровне http для бизнес ошибок - всем все будет понятно

Код: javascript
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
HTTP/1.1 400 Bad Request
Content-Type: application/json; charset=utf-8
Content-Length: 320

{
  "Message": "The request is invalid.",
  "ModelState": {
    "item": [
      "Required property 'Name' not found in JSON. Path '', line 1, position 14."
    ],
    "item.Name": [
      "The Name field is required."
    ],
    "item.Price": [
      "The field Price must be between 0 and 999."
    ]
  }
}



спасибо
...
Рейтинг: 0 / 0
04.10.2018, 09:32
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39712806
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
monstrUвот такой ответ ты должен возвращать на уровне http для бизнес ошибок - всем все будет понятно
Угу. ASP 2012 год?
...
если мы делаем API для всего и вся, то зачем посылать кучу текста на английском?
Его на экран не выводят. Читает его программа а не человек.
Поэтому имхо берем пример с оракле.
Возврат кода ошибки дополнительно если требуется.
При rest обычно не требуется. MS rest начал делать совсем недавно, поэтому доки устарели.
Помнить о безопасности и не давать лишней инфы.
А клиент по коду ошибки уже сам решит.
...
Это для api rest. В ASP можно пробросить и текст и что угодно с бэка на фронт.
...
Рейтинг: 0 / 0
04.10.2018, 09:53
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39712812
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
WaspNewCorePetro123,

Я программист бэкэнда. Фронтэндер другой программист.
Моя задача предоставить удобный API.
Программисту клиента не нужен текст ошибки на английском с ошибками.
Ему нужен код ошибки.
А при rest бизнес код ошибки часто совпадает с кодами http транспорта.
Причем часто это не значит всегда, т.к. FullRest это приближение к идеальному rest.
...
Рейтинг: 0 / 0
04.10.2018, 10:03
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39712817
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
Petro123WaspNewCorePetro123,

Я программист бэкэнда. Фронтэндер другой программист.
Моя задача предоставить удобный API.
Программисту клиента не нужен текст ошибки на английском с ошибками.
Ему нужен код ошибки.
А при rest бизнес код ошибки часто совпадает с кодами http транспорта.
Причем часто это не значит всегда, т.к. FullRest это приближение к идеальному rest.
Клиент не будет заводить словарь твоих кодов, он может получить локализованный текст ошибки и не парится.
То, что клиент свою формочку перед запросом проверит тоже хорошо.
...
Рейтинг: 0 / 0
04.10.2018, 10:09
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39712824
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
Парамон,
Да. Только:
1. Не парятся новички.
2. Для них есть справочник ошибок сразу локализованный в отдельном методе.
3. Это не сайт, а API.
4. Бери пример с оракла. Там одна строка ошибки с кодом. Всё.
...
Рейтинг: 0 / 0
04.10.2018, 10:16
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39712839
monstrU
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
monstrU
Участник
Petro123monstrUвот такой ответ ты должен возвращать на уровне http для бизнес ошибок - всем все будет понятно
Угу. ASP 2012 год?
...
если мы делаем API для всего и вся, то зачем посылать кучу текста на английском?
Его на экран не выводят. Читает его программа а не человек.
Поэтому имхо берем пример с оракле.
Возврат кода ошибки дополнительно если требуется.
При rest обычно не требуется. MS rest начал делать совсем недавно, поэтому доки устарели.
Помнить о безопасности и не давать лишней инфы.
А клиент по коду ошибки уже сам решит.
...
Это для api rest. В ASP можно пробросить и текст и что угодно с бэка на фронт.

почитай еще раз
Exception Handling in ASP.NET Web API
03/12/2012

статья за 2012 год - оно конечно достаточно старая, но подход оправданный

я специально написал нужны ответ в самом примитивном http

HTTP/1.1 400 Bad Request
Content-Type: application/json; charset=utf-8
Content-Length: 320

{
// тут вот постарайся абстрагироваться и написать удобный формат ответа об ошибке
}

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

но подход - возвращать 400 + Json в Body ответа надеюсь без возражений проходит?
...
Рейтинг: 0 / 0
04.10.2018, 10:37
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39712847
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
monstrUстатья за 2012 год - оно конечно достаточно старая, но подход оправданныйчем отличается Core, rest от ASP в курсе?
Что даже MS совместимость похерил!
...
Рейтинг: 0 / 0
04.10.2018, 10:45
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39712852
Дмитрий Мух
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дмитрий Мух
Участник
monstrUlove_bachОбъясните гуры и мне

Запрос:
если отработало, то 200 + данные, или 404, если данные не удалось вернуть (нет данных, кривой url)

Команда:
если отработало, то 200/201 + данные
если есть ошибки бизнес логики, то ...
если падает, то 500 (и пофиг почему, логируем на бэке)
если кривой запрос, то 400 + ...

правильно думаю? что тут вместо "..." по феншую?

вот тут более менее удачное описание подхода к тому, какие ошибки надо использовать.
+1, норм

И, специально для ботов, 2015-го года, с текстом на русском и выводом на экран
...
Рейтинг: 0 / 0
04.10.2018, 10:56
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39712856
handmadeFromRu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
handmadeFromRu
Участник
Petro123Парамон,
Да. Только:
1. Не парятся новички.
2. Для них есть справочник ошибок сразу локализованный в отдельном методе.
3. Это не сайт, а API.
4. Бери пример с оракла. Там одна строка ошибки с кодом. Всё.

вот тут у меня двоякое ощущение вроде и коды хороши, а вроде и текст приятно понять сходу что не так. я пока для себя не определился тут и чаще вываливаю текст бл слоя. быть может коды не распробовал
...
Рейтинг: 0 / 0
04.10.2018, 11:04
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39712865
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
handmadeFromRu,
Ну и я не против текста и кода.
Только текст должен короткий и простой. Не как выше чел привёл.
Есть ешё и форму назад шлют)))
...
Рейтинг: 0 / 0
04.10.2018, 11:11
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39712875
Дмитрий Мух
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дмитрий Мух
Участник
handmadeFromRuPetro123Парамон,
Да. Только:
1. Не парятся новички.
2. Для них есть справочник ошибок сразу локализованный в отдельном методе.
3. Это не сайт, а API.
4. Бери пример с оракла. Там одна строка ошибки с кодом. Всё.

вот тут у меня двоякое ощущение вроде и коды хороши, а вроде и текст приятно понять сходу что не так. я пока для себя не определился тут и чаще вываливаю текст бл слоя. быть может коды не распробовал
Когда пишешь на JavaScript клиента для API, то код 400 и сообщение "Required property 'Name' not found in JSON. Path '', line 1, position 14." ой как помогают.
Сразу видишь, что ты кривой JSON сформировал и где конкретно ошибка.

Подходу сто лет в обед. Так ещё в 2008-м делал для интеграции с туроператором Библио Глобус.
У них прям требование было: возвращать state по каждому из переданных элементов.
...
Рейтинг: 0 / 0
04.10.2018, 11:22
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39712932
monstrU
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
monstrU
Участник
Petro123handmadeFromRu,
Ну и я не против текста и кода.
Только текст должен короткий и простой. Не как выше чел привёл.
Есть ешё и форму назад шлют)))

интересно, если пример я дал как

Код: javascript
1.
2.
3.
4.
5.
6.
7.
8.
HTTP/1.1 400 Bad Request
Content-Type: application/json; charset=utf-8
Content-Length: 320

{
   ErrorCode: '1001',
   Message: 'Указанный email пользователя не зарегистрирован'
}



споров было бы меньше
...
Рейтинг: 0 / 0
04.10.2018, 12:38
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39712937
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
monstrUPetro123handmadeFromRu,
Ну и я не против текста и кода.
Только текст должен короткий и простой. Не как выше чел привёл.
Есть ешё и форму назад шлют)))

интересно, если пример я дал как

Код: javascript
1.
2.
3.
4.
5.
6.
7.
8.
HTTP/1.1 400 Bad Request
Content-Type: application/json; charset=utf-8
Content-Length: 320

{
   ErrorCode: '1001',
   Message: 'Указанный email пользователя не зарегистрирован'
}




споров было бы меньше
Он скорее всего именно про "Required property 'Name' not found in JSON. Path '', line 1, position 14."
Этот текст для него длинный и сложный.
...
Рейтинг: 0 / 0
04.10.2018, 12:40
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39712970
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
ViPRosСам ты глупый.
Заставь клиента послать правильную информацию в правильный адресат.
А то всех ящеров, роботов и т.д. в поликлинику - лечить (и так блин везде очереди).

Мне непонятно, когда путают техническую и какую-нибудь организационную области.
Ошибки нужно проверять и валидировать на всех уровнях. Никогда нельзя полагать, что кто-то из участников системы типа ДОЛЖЕН слать/принимать только валидную информацию.

Это верно даже внутри разработки. Все методы, например, принимающие объекты по ссылке, должны проверять на null, даже если в требованиях указано, что null не должен передаваться. Так называемый null hell никто не отменял, и вообще.

ты какой-то странный.
...
Рейтинг: 0 / 0
04.10.2018, 13:30
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39712971
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
monstrU
Код: javascript
1.
HTTP/1.1 400 Bad Request



бэд реквест относится только к ошибкам уровня протокола, но не данных

смотрю, бардак в головах достигает эпических размеров.

печаль, печаль, печаль....
...
Рейтинг: 0 / 0
04.10.2018, 13:31
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39712974
love_bach
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
love_bach
Участник
hVosttmonstrU
Код: javascript
1.
HTTP/1.1 400 Bad Request



бэд реквест относится только к ошибкам уровня протокола, но не данных

смотрю, бардак в головах достигает эпических размеров.

печаль, печаль, печаль....

покажи как надо
...
Рейтинг: 0 / 0
04.10.2018, 13:32
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39712981
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
love_bach,

в смысле, как надо?
идёте читаете доку по HTTP ошибкам

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

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

если всё равно непонятно, рисуете таблицу своих ошибок и ситуаций, в табличке, где относите ошибки к тому или иному уровню.

тут ничего сложного.
...
Рейтинг: 0 / 0
04.10.2018, 13:36
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39712991
monstrU
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
monstrU
Участник
hVostt,

картина на форуме повторяется
1. задают вопрос
2. дают свой вариант ответа
поступает гневный пост "#всехерня #такнельзя #вывседураки"

просят дай твой вариант ответа - пишут иди в гугл.

снова спрошу - как надо то?
как надо возвращать бизнес ошибки из rest сервиса ?
...
Рейтинг: 0 / 0
04.10.2018, 13:53
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39713048
Addx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Addx
Участник
monstrUhVostt,

картина на форуме повторяется
1. задают вопрос
2. дают свой вариант ответа
поступает гневный пост "#всехерня #такнельзя #вывседураки"

просят дай твой вариант ответа - пишут иди в гугл.

снова спрошу - как надо то?
как надо возвращать бизнес ошибки из rest сервиса ?

Характер ошибки - через коды, детали через json.
Запрос при отсутствии объекта в базе болжен возвращать код из 2ххх
Исключение - логика на чистых CRUD операциях, тут нужно уточнение архитектуры.
Так понятно?
Или и тут что-то нужно пояснить?
...
Рейтинг: 0 / 0
04.10.2018, 15:10
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39713054
love_bach
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
love_bach
Участник
AddxЗапрос при отсутствии объекта в базе болжен возвращать код из 2ххх

тут вроде сошлись на 404

AddxИсключение - логика на чистых CRUD операциях, тут нужно уточнение архитектуры.


это о чем?
...
Рейтинг: 0 / 0
04.10.2018, 15:19
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39713060
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
monstrUкартина на форуме повторяется
1. задают вопрос
2. дают свой вариант ответа
поступает гневный пост "#всехерня #такнельзя #вывседураки"

просят дай твой вариант ответа - пишут иди в гугл.

снова спрошу - как надо то?
как надо возвращать бизнес ошибки из rest сервиса ?

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

как надо я уже сказал.
что не понятно?
...
Рейтинг: 0 / 0
04.10.2018, 15:24
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39713070
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ViPRos
Участник
hVosttViPRosСам ты глупый.
Заставь клиента послать правильную информацию в правильный адресат.
А то всех ящеров, роботов и т.д. в поликлинику - лечить (и так блин везде очереди).

Мне непонятно, когда путают техническую и какую-нибудь организационную области.
Ошибки нужно проверять и валидировать на всех уровнях. Никогда нельзя полагать, что кто-то из участников системы типа ДОЛЖЕН слать/принимать только валидную информацию.

Это верно даже внутри разработки. Все методы, например, принимающие объекты по ссылке, должны проверять на null, даже если в требованиях указано, что null не должен передаваться. Так называемый null hell никто не отменял, и вообще.

ты какой-то странный.
заставь клиента (вызывающий код) сделать все это
...
Рейтинг: 0 / 0
04.10.2018, 15:31
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39713089
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
ViPRosзаставь клиента (вызывающий код) сделать все это

поэтому валидация должна быть на всех уровнях.
как раз ещё и потому, зазработчик клиента может оказаться чукчей (как это обычно и бывает), и не делать по уму.
...
Рейтинг: 0 / 0
04.10.2018, 15:53
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39713135
Addx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Addx
Участник
love_bachAddxЗапрос при отсутствии объекта в базе болжен возвращать код из 2ххх

тут вроде сошлись на 404



Если Вам нужна голосовалка, повесьте опрос.
Вы хотите простой ответ - я его даю.
Могу написать "поищите в интернете, тема заезженая, давно изучена со всех сторон, все плюсы и минусы известны"

love_bachAddxИсключение - логика на чистых CRUD операциях, тут нужно уточнение архитектуры.


это о чем?

Если Вы не знаете, что такое CRUD операции и API, построенное на нем, то Вам это не нужно.
Просто проигнорируйте.
...
Рейтинг: 0 / 0
04.10.2018, 17:07
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39713201
love_bach
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
love_bach
Участник
AddxЕсли Вы не знаете, что такое CRUD операции и API, построенное на нем, то Вам это не нужно.
Просто проигнорируйте.

не проигнорирую. раз уж сказали А, говорите Б:
- что такое "чистые CRUD операции"?
- почему API для "чистых CRUD операций" в контексте темы топика как-то принципиально отличается?
...
Рейтинг: 0 / 0
04.10.2018, 18:23
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39713241
Addx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Addx
Участник
love_bachAddxЕсли Вы не знаете, что такое CRUD операции и API, построенное на нем, то Вам это не нужно.
Просто проигнорируйте.

не проигнорирую. раз уж сказали А, говорите Б:
- что такое "чистые CRUD операции"?
- почему API для "чистых CRUD операций" в контексте темы топика как-то принципиально отличается?

Это вопросы для темы "Программирование".
К ASP.NET (и к кодам ошибок) непосредственного отношения не имеют.
CRUD операции - это устоявшийся термин. Вы же не просите объяснить, что такое ASP или .NET?
Одно дело, когда Вас интересует неочевидный момент, другое дело - если Вы не знаете базовых вещей (в рамках этой темы, это не обвинение в невежестве вообще).
Какой смысл читать лекции?
Если же вопрос относился к слову "чистый", то тоже странно, что это непонятно.
Словосочетания "написано на чистом C#(или С, или ассемблере)" тоже вызывают вопросы?
...
Рейтинг: 0 / 0
04.10.2018, 19:54
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39713242
love_bach
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
love_bach
Участник
Addxlove_bachпропущено...


не проигнорирую. раз уж сказали А, говорите Б:
- что такое "чистые CRUD операции"?
- почему API для "чистых CRUD операций" в контексте темы топика как-то принципиально отличается?

Это вопросы для темы "Программирование".
К ASP.NET (и к кодам ошибок) непосредственного отношения не имеют.
CRUD операции - это устоявшийся термин. Вы же не просите объяснить, что такое ASP или .NET?
Одно дело, когда Вас интересует неочевидный момент, другое дело - если Вы не знаете базовых вещей (в рамках этой темы, это не обвинение в невежестве вообще).
Какой смысл читать лекции?
Если же вопрос относился к слову "чистый", то тоже странно, что это непонятно.
Словосочетания "написано на чистом C#(или С, или ассемблере)" тоже вызывают вопросы?

золотое правило: если нечего сказать по теме, лучше ничего не говрить
...
Рейтинг: 0 / 0
04.10.2018, 19:56
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39713244
Addx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Addx
Участник
love_bachзолотое правило: если нечего сказать по теме, лучше ничего не говрить

Зачем задавать вопросы, если не хотите, чтобы на них отвечали?
Я изначально предложил Вам проигнорировать свой ответ, но Вы начали задавать вопросы.
Я дал Вам советы, и не моя вина, что Вам они не понравились.
...
Рейтинг: 0 / 0
04.10.2018, 20:11
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39713245
love_bach
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
love_bach
Участник
Addxlove_bachзолотое правило: если нечего сказать по теме, лучше ничего не говрить

Зачем задавать вопросы, если не хотите, чтобы на них отвечали ?
Я изначально предложил Вам проигнорировать свой ответ, но Вы начали задавать вопросы.
Я дал Вам советы, и не моя вина, что Вам они не понравились.

ответы в стиле Petro123 меня не интересуют. они повышают энтропию вселенной и больше они ни на что не годятся.
а вам задано 2 конкретных вопроса. возможно, ответ на них будет для меня интересен
...
Рейтинг: 0 / 0
04.10.2018, 20:15
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39713292
stenford
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
stenford
Участник
monstrUкартина на форуме повторяется
1. задают вопрос
2. дают свой вариант ответа
поступает гневный пост "#всехерня #такнельзя #вывседураки"

просят дай твой вариант ответа - пишут иди в гугл.

снова спрошу - как надо то?
как надо возвращать бизнес ошибки из rest сервиса ?
не обращай внимания на этого дилетанта, "как правильно" у тебя было хорошо расписано
...
Рейтинг: 0 / 0
05.10.2018, 02:13
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39713344
Дмитрий Мух
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дмитрий Мух
Участник
love_bach,

имхо достаточно ответов, чтобы попробовать
как начнёте писать код, так всё и сложится
...
Рейтинг: 0 / 0
05.10.2018, 09:18
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39713348
love_bach
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
love_bach
Участник
Дмитрий Мухlove_bach,

имхо достаточно ответов, чтобы попробовать
как начнёте писать код, так всё и сложится

да я уже давно попробовал. просто некоторые сомнения возникали
...
Рейтинг: 0 / 0
05.10.2018, 09:27
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39713940
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
hVosttmonstrU
Код: javascript
1.
HTTP/1.1 400 Bad Request



бэд реквест относится только к ошибкам уровня протокола, но не данных

смотрю, бардак в головах достигает эпических размеров.

печаль, печаль, печаль....
Букварь почитай Exception Handling in ASP.NET Web API
...
Рейтинг: 0 / 0
06.10.2018, 21:21
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39713944
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
ПарамонБукварь почитай Exception Handling in ASP.NET Web API

И в чём противоречие?

Если ты принимаешь число, а тебе присылают строку -- это бед реквест.
Или ты ожидаешь поле Name, а в запросе его нет, то это тоже бед реквест.
Это нарушение контракта.

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

Поэтому, читать буквари -- это гуд.
Но пожалуйста, читайте НЕ ТОЛЬКО буквари, но и пользуйтесь той штукой, которая находится внутри головы.
Очень советую.
...
Рейтинг: 0 / 0
06.10.2018, 22:02
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39713956
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
hVosttПарамонБукварь почитай Exception Handling in ASP.NET Web API

И в чём противоречие?

Если ты принимаешь число, а тебе присылают строку -- это бед реквест.
Или ты ожидаешь поле Name, а в запросе его нет, то это тоже бед реквест.
Это нарушение контракта.

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

Поэтому, читать буквари -- это гуд.
Но пожалуйста, читайте НЕ ТОЛЬКО буквари, но и пользуйтесь той штукой, которая находится внутри головы.
Очень советую.
Что то не заметно, что ты эту штуку используешь в последнее время. То что сущность не найдена в базе, это ошибка протокола или адрес плохой ага? А статус 404 в букваре не смущает? А то, что для JSON все строки, а не числа и только приложение решает ошибка это или нет, удивительно да? ))
...
Рейтинг: 0 / 0
07.10.2018, 00:39
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39713958
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
hVosttА если тебе присылают правильно оформленное имя пользователя при регистрации, но оно уже зарезервировано, то это не бед реквест.
Кроме бед реквест есть ещё статусы, 409 как вариант. Ты почитай на досуге.
...
Рейтинг: 0 / 0
07.10.2018, 00:54
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714170
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
Парамон,

Опять не вижу противоречий.

409 напрямую связан с ресурсом, на который указывает URL

если твой PUT будет возвращать 409 в ответ на конфликт, связанный с каким-нибудь ID, указанным внутри JSON, ты очевидно делаешь фигню.

404 не смущает, так как это связано с URL, это также отвечает критериям безопасности.

ситуаций самых разных в ПО может быть тысячи, а кодов HTTP ошибок у тебя десяток.
вот это тебя не смущает?

приложение решает ошибка это или нет, но уровень принятия решения -- это большая разница.
давай ещё бизнес-модуль будет думать о том, с каким кодом вернуть ответ клиенту, не?

говнокодить так говнокодить, не нужно стесняться.
...
Рейтинг: 0 / 0
08.10.2018, 01:16
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714200
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
hVosttесли твой PUT будет возвращать 409 в ответ на конфликт, связанный с каким-нибудь ID, указанным внутри JSON, ты очевидно делаешь фигню
Ты будешь возвращать 200?

На счёт тысяч ошибок. Главное дать клиенту понять, запрос success или fail, на это статусов хватает. Как твоём случае клиент об этом узнает, чтобы стандартно?
...
Рейтинг: 0 / 0
08.10.2018, 08:35
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714214
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
ПарамонТы будешь возвращать 200?

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

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

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

Подумай.
...
Рейтинг: 0 / 0
08.10.2018, 09:27
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714255
monstrU
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
monstrU
Участник
hVosttПарамонТы будешь возвращать 200?

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

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

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

Подумай.

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

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

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

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

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

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

вот реальный пример успешного запроса сеансов для контрагента с http ответом 200
Код: javascript
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
[
	{
		"id": 52,
		"showtime": "2018-10-08T23:59:00.000+03:00",
		"status": "on_sale",
		"performance_id": 12,
		"hall_id": 11,
		"stop_reservation_time": "2018-10-08T23:44:00.000+03:00",
		"stop_long_reservation_time": "2018-10-08T23:44:00.000+03:00",
		"organization_id": 0
	}	
]



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

Код: javascript
1.
2.
3.
4.
5.
6.
{
	"response_status": "error",
	"response_status_human": "Произошла ошибка",
	"error": "404 Not-found",
	"error_human": "Такого метода или ресурса нет. Ссылка на документацию https://demo.edinoepole.ru/api/contractors/docs"
}



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

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

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

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

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

1. для успешных операций и ошибок логики возвращать 200. в этом случае в ответе нужно заводит поле, в котором может быть записана возможная ошибка логики
2. для успешных операций нужно возвращать 200, для ошибок логики возвращать один код 4xx. в этом случае в случае успешной операции возвращать данные с ответом, в случае ошибки логики возвращать код ошибки и возможное описание ошибки
...
Рейтинг: 0 / 0
08.10.2018, 10:28
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714304
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
hVostt,

Ответ вопросом на вопрос ещё терпимо, но мой вопрос уже содержит ответ, так что это либо очень густой сумрак, либо не желание видеть очевидное.

Да, и почему только 200? 201 на удачный инсерт тоже не используем? ))

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

Весь мир так работает, хочешь оставаться Дартаньяном, пожалуйста )
...
Рейтинг: 0 / 0
08.10.2018, 11:26
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714316
handmadeFromRu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
handmadeFromRu
Участник
hVosttА если тебе присылают правильно оформленное имя пользователя при регистрации, но оно уже зарезервировано, то это не бед реквест.

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

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


если данные нарушают какое-то бизнес-правило, то 40x. потому что это ошибка и не важно ты её ожидал или нет. механизм прокидывания ошибок из кишков бизнес слоя через генерацию ошибок вроде обычный(а там уже Ui как надо выведет если надо вообще) так почему я не могу использовать статусы ошибок http чтоб говорить http клиентам сходу что у меня ошибка и все http клиенты умеют обработать такую ситуацию без дополнительного кода. я видел апи того же яндекса и других контор что на ошибку отвечают 200 и меняли дто в ответе либ делали "суперобъект" с заранее заложенными свойствами полями ошибки, вот только зачем. В чем минус ответа со статусом? чему это противоречит? то что на коды ошибок http вещают свои ошибки? ну и ладно. но почему бы не использовать то что есть. я не вижу где ты нашел кашу в голове, по мне люди идут по пути простоты, а не придумывания велосипедов.
...
Рейтинг: 0 / 0
08.10.2018, 11:37
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714385
Addx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Addx
Участник
handmadeFromRu я видел апи того же яндекса и других контор что на ошибку отвечают 200 и меняли дто в ответе либ делали "суперобъект" с заранее заложенными свойствами полями ошибки, вот только зачем.

И действительно, почти все серьезные конторы так делают. Дураки, наверное.
...
Рейтинг: 0 / 0
08.10.2018, 13:35
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714391
Addx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Addx
Участник
ПарамонhVostt,

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

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

А можно про весь мир поподробнее? Пару примеров. Да хотя бы один?
...
Рейтинг: 0 / 0
08.10.2018, 13:38
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714398
monstrU
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
monstrU
Участник
AddxПарамонhVostt,

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

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

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

я привел пример крупной билетной площадки Единое поле , которая так работает
...
Рейтинг: 0 / 0
08.10.2018, 13:55
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714404
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
ПарамонОтвет вопросом на вопрос ещё терпимо, но мой вопрос уже содержит ответ, так что это либо очень густой сумрак, либо не желание видеть очевидное.

У тебя вопрос глупый и расчитан на дурака. Как договорятся клиент с сервером (точнее их разработчики), так и будет "узнавать". А на мой вопрос ты отвечать не стал, так как ответ тебе явно не нравится.

ПарамонДа, и почему только 200? 201 на удачный инсерт тоже не используем? ))

Пошли какие-то странные придирки. 201 используем, но сути это не меняет.

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

Я тебе ещё раз задам свой вопрос. Ситуаций в ПО тысячи. Кодов HTTP у тебя десяток. Что там тебе вдруг внезапно стало "очевидно", можешь поведать деревенщинам?


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

Резюме похоже на слив.
...
Рейтинг: 0 / 0
08.10.2018, 14:04
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714405
Addx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Addx
Участник
monstrU
я привел пример крупной билетной площадки Единое поле , которая так работает

Да, но метод работает совсем не так, как Вы пишете.

monstrU2. успешный ответ + ошибка бизнес логики - ответ 4хх


Тут и близко такого нет. Это совсем не про бизнес логику.
...
Рейтинг: 0 / 0
08.10.2018, 14:04
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714413
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
handmadeFromRuеще какой бед так как противоречит твоей бизнес логики.

С фига ли? Ошибки в мониторе это проблема, которая фиксируется, исследуется и при необходимости устраняется.
А когда пользователи ошибаются с вводом, делают невалидные действия с точки зрения бизнеса, таких ситуаций тысячи и тысячи -- какие же это ошибки? Зачем мне это в статистике работы ПО? Я что админам должне объяснять все 100500 ситуаций?

Вы ребята вообще чем занимались, с каких деревьев слезли )) Ну и мрак....


handmadeFromRuесли данные нарушают какое-то бизнес-правило, то 40x.

Это твои фантазии. Но и не только твои, но и многих. И это довольно распространённая проблема.


handmadeFromRuмеханизм прокидывания ошибок из кишков бизнес слоя через генерацию ошибок вроде обычный

И как твой бизнесовый "механизм" должен в зависимости от ситуации назначить "правильный" код? ))


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

Как раз таки написанное тобой это именно что велосипеды, натуральным образом. Да ещё и с квадратными колёсами. А насчёт "просто", так всегда, у каждого человека свой бред это всегда "просто". Но ни под какие обоснования не ложится.

Просто "так захотелось".

https://developer.mozilla.org/ru/docs/Web/HTTP/Status/400

где тут про бизнес логику? RFC почитайте.

я уже не прошу головой думать. видимо, это сложно.
...
Рейтинг: 0 / 0
08.10.2018, 14:12
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714420
Addx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Addx
Участник
hVostt
Как раз таки написанное тобой это именно что велосипеды, натуральным образом. Да ещё и с квадратными колёсами. А насчёт "просто", так всегда, у каждого человека свой бред это всегда "просто". Но ни под какие обоснования не ложится.

Просто "так захотелось".

https://developer.mozilla.org/ru/docs/Web/HTTP/Status/400

где тут про бизнес логику? RFC почитайте.

я уже не прошу головой думать. видимо, это сложно.

Ну как же - там основной вклад AlexeyVasiliev -> Vasiliev -> Vasya -> Вася )))
Да и код 4xxx - видимо не 400, а 418. )))
...
Рейтинг: 0 / 0
08.10.2018, 14:21
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714424
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
monstrUя вот продолжу обсуждение.

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

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


давай говорить 2xx, а то это повод цепануться )

я уже сказал про ошибки уровня протокола. протокол это URL, формат данных, заголовки.
а ошибки логики, это неправильные действия пользователя. именно действия, а не когда он лезет в URL и меняет что-то там от балды. или какой-то кривой клиент отправляет неправильные данные, или приложение клиента реализовано криво. или нет авторизации, это уровень протокола (URL => нет доступа).

по мне, тут всё понятно и очевидно.

от чего такое бурление и непонимание возникает -- не понимаю.

вообще не понимаю. что за мрак.

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

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

давайте придумаем свои коды.

444 - так себе ошибка, не критичная, ну бывает
555 - ооо, это уже серьезно
666 - ваще капец, алярм!
...
Рейтинг: 0 / 0
08.10.2018, 14:24
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714429
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
hVosttПошли какие-то странные придирки. 201 используем, но сути это не меняет.
Очень даже меняет, 201 это логика протокола такая да, или адрес удачный?
И почему там 200 не хватило вдруг?
hVosttРезюме похоже на слив.
AddxА можно про весь мир поподробнее? Пару примеров. Да хотя бы один?
Казалось бы, что может быть проще, чем поискать самому.

HTTP response code for POST when resource already exists

Which HTTP response code for “This email is already registered”?

Там один внизу списка, даже пытался высказать мнение похожее на ваше, но он пехапешник, что с него взять. ))

Теперь мне накидайте подтверждение вашего бестпрактиса. И хвост покажи если можно твой json респонс, порадуй а?
Какое ты там поле придумал для статуса ошибки? ))
...
Рейтинг: 0 / 0
08.10.2018, 14:28
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714434
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
Парамон,

Ну так как ты в очередной раз проигнорил мой вопрос.
Сослался на какие-то тёрки на стеке
Проигнорил RFC.


Ну действительно. Что с тебя взять? ))
...
Рейтинг: 0 / 0
08.10.2018, 14:32
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714435
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
ПарамонКакое ты там поле придумал для статуса ошибки? ))

Никакого я поля не придумывал. Зачем? У нас всё серьёзно.
...
Рейтинг: 0 / 0
08.10.2018, 14:33
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714437
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
ПарамонОчень даже меняет, 201 это логика протокола такая да, или адрес удачный?
И почему там 200 не хватило вдруг?

201 это не просто код ответа, там ещё заголовок есть, это уровень протокола, так как возвращается URL созданного ресурса.

Если ты под это какой-то своё больное воображение подгоняешь, та ради бога.
Я не против.
...
Рейтинг: 0 / 0
08.10.2018, 14:35
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714439
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
hVosttдавайте придумаем свои коды.

444 - так себе ошибка, не критичная, ну бывает
555 - ооо, это уже серьезно
666 - ваще капец, алярм!

Все уже придумали, нужно просто пытаться включить моск и почитать доку.

авторAll HTTP response status codes are separated into five classes (or categories).

1xx (Informational): The request was received, continuing process
2xx (Successful): The request was successfully received, understood, and accepted
3xx (Redirection): Further action needs to be taken in order to complete the request
4xx (Client Error): The request contains bad syntax or cannot be fulfilled
5xx (Server Error): The server failed to fulfill an apparently valid request

Этого хватает на все твои фантазии с головой. Это стандартный подход.
...
Рейтинг: 0 / 0
08.10.2018, 14:36
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714448
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
hVosttСослался на какие-то тёрки на стеке


Какие терки? Там задан прямой и недвусмысленный вопрос новичка, такой же как и твой. И дан простой ответ, который все единогласно поддержали.

Уже тыкаю в непервую ссылку, бесполезно походу. (

hVosttНикакого я поля не придумывал. Зачем? У нас всё серьёзно.
Пример и ссылки будут?
...
Рейтинг: 0 / 0
08.10.2018, 14:50
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714452
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
hVosttЯ тебе ещё раз задам свой вопрос. Ситуаций в ПО тысячи. Кодов HTTP у тебя десяток. Что там тебе вдруг внезапно стало "очевидно", можешь поведать деревенщинам?
Смотри пост выше )
...
Рейтинг: 0 / 0
08.10.2018, 14:51
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714470
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
ПарамонВсе уже придумали, нужно просто пытаться включить моск и почитать доку.

Ну так почитай. Кинь RFC.


ПарамонЭтого хватает на все твои фантазии с головой. Это стандартный подход.

Вот я и смотрю, что у вас одни фантазии. И вообще не пойму, с чем вы спорите ))
...
Рейтинг: 0 / 0
08.10.2018, 15:15
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714473
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
hVosttПроигнорил RFC

Там чел как раз тыкает в тот же RFC.

What http status code should the Web API return for a business rule failure?

Явный намек на то, что статус 200 с ошибкой это тяжелая клиника )
...
Рейтинг: 0 / 0
08.10.2018, 15:19
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714475
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
ПарамонКакие терки? Там задан прямой и недвусмысленный вопрос новичка, такой же как и твой. И дан простой ответ, который все единогласно поддержали.

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

Давай по твоим ссылкам


Парамон HTTP response code for POST when resource already exists

Ошибка по протоколу, применения кода 409 уместно, так как создание ресурса по URL вызывает конфликт.

The 409 (Conflict) status code indicates that the request could not
be completed due to a conflict with the current state of the target
resource . This code is used in situations where the user might be
able to resolve the conflict and resubmit the request. The server
SHOULD generate a payload that includes enough information for a user
to recognize the source of the conflict.

Conflicts are most likely to occur in response to a PUT request. For
example, if versioning were being used and the representation being
PUT included changes to a resource that conflict with those made by
an earlier (third-party) request, the origin server might use a 409
response to indicate that it can't complete the request. In this
case, the response representation would likely contain information

Если вы не в состоянии работать с документацией, даю ещё одну цитату из RFC

The target of an HTTP request is called a "resource". HTTP does not
limit the nature of a resource; it merely defines an interface that
might be used to interact with resources. Each resource is
identified by a Uniform Resource Identifier (URI), as described in
Section 2.7 of [RFC7230].


И что ты хотел доказать? Ты просто услышал звон, да захотел свои неуместные 5 копеек вставить?
Слабо кинуть ссыль на RFC? Конечно слабо, лучше загуглить какую-то фигню.
...
Рейтинг: 0 / 0
08.10.2018, 15:21
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714481
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
ПарамонЯвный намек на то, что статус 200 с ошибкой это тяжелая клиника )

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

В общем, мрак.

Давай на примитивном языке?

Я тебе говорю, ДАЙ МНЕ ЯБЛОК.
Ты отвечаешь У МЕНЯ НЕТ ЯБЛОК (200, так как ты меня понял, но яблок у тебя нет).
Когда я тебе говорю, ВЫПАК№ЦКаЫа32, ты говоришь Я ТЕБЯ НЕ ПОНИМАЮ.

Реал, мне уже страшно становится.
Вы что серьёзно вот этот вот, гоните, не знаете и не понимаете HTTP?

Мрааааак.
...
Рейтинг: 0 / 0
08.10.2018, 15:28
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714482
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
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 (e.g., malformed request syntax, invalid request
message framing, or deceptive request routing).

Ошибки логики приложения. Бизнес-логики. Тут явно об этом сказано, да?

Фантазёры блеать.
...
Рейтинг: 0 / 0
08.10.2018, 15:31
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714484
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
hVosttНу что ты доказать-то хочешь? Вы даже претензию сформулировать не можете, о чём вообще говорить?hVosttИ что ты хотел доказать?

Я про вот этот бред, если ты еще не понял.
hVosttА если тебе присылают правильно оформленное имя пользователя при регистрации, но оно уже зарезервировано, то это не бед реквест.hVosttЕсли это ошибка логики, ошибка ввода пользователем (валидация), естественно это будет 200.


hVosttТы просто услышал звон, да захотел свои неуместные 5 копеек вставить?
Слабо кинуть ссыль на RFC? Конечно слабо, лучше загуглить какую-то фигню.
Вижу ты включил обратку, пытаясь увести спор в другое русло, но как бы все уже понятно )
И походу смысла своих цитат по RFC ты не осиливаешь, может перевод сложный?
Повторю:
ПарамонЯвный намек на то, что статус 200 с ошибкой это тяжелая клиника )
...
Рейтинг: 0 / 0
08.10.2018, 15:40
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714486
Addx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Addx
Участник
Парамон
HTTP response code for POST when resource already exists



Пользователь Wrikken очень авторитетен для нас. У него же столько лайков! Его мнение на порядок важнее RFC.)
И Google c Яндексом в своих API работают по полям в возврате, а не по статусам. Их мнение тоже неинтересно. У них лайков меньше. )))
Если у Вас вся бизнес логика заключается в CRUD операциях, то подход с кодами возврата допустим. (опустим вопросы об архитектуре таких приложений).
Там может быть ответ только да/нет, и только одна причина отказа. Соответствие типов запросов (GET, POST, PUT, DELETE) очень строгое.
...
Рейтинг: 0 / 0
08.10.2018, 15:48
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714487
Addx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Addx
Участник
hVostt,

Вы все еще надеетесь убедить логикой и отсылками к документации? )))
...
Рейтинг: 0 / 0
08.10.2018, 15:50
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714488
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
hVostt 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 (e.g., malformed request syntax, invalid request
message framing, or deceptive request routing).

Ошибки логики приложения. Бизнес-логики. Тут явно об этом сказано, да?

Фантазёры блеать.
Да, все фантазеры, а ты Дартаньян. )

Сказно сервер не смог по какой то причине обработать запрос, и мы хотим указать на это клиенту. Тебе дали несколько вариантов проблемы, но не все. Далее мы в состоянии понять, что это любая причина связанная с запросом клиента, по решению сервера, а именно кода там написаного, или ты из танка так и не вылезешь?
...
Рейтинг: 0 / 0
08.10.2018, 15:51
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714489
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
ПарамонЯ про вот этот бред, если ты еще не понял.
hVosttА если тебе присылают правильно оформленное имя пользователя при регистрации, но оно уже зарезервировано, то это не бед реквест.hVosttЕсли это ошибка логики, ошибка ввода пользователем (валидация), естественно это будет 200.

А пояснить ты можешь? Я пояснил, и мои аргументы чёткие и уверенные.
Прости, но "там какие-то ребята говорят.. бла-бла", не аргумент.

Если у тебя это всё, тогда это твой слив.


ПарамонВижу ты включил обратку, пытаясь увести спор в другое русло, но как бы все уже понятно )
И походу смысла своих цитат по RFC ты не осиливаешь, может перевод сложный?
Повторю:
ПарамонЯвный намек на то, что статус 200 с ошибкой это тяжелая клиника )

Это не ошибка, а нормальное поведение.
То, что пользователь может ошибиться при вводе -- это нормальное поведение, абсолютно предсказуемое.
Слово "ошибка" здесь в понятии, "ошибка ввода", или "логическая ошибка невозможности операции" и т.д.

Ты прав. Клиника. Даже с терминологией проблемы.
...
Рейтинг: 0 / 0
08.10.2018, 15:52
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714490
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
AddxhVostt,

Вы все еще надеетесь убедить логикой и отсылками к документации? )))

Мы просто столкнулись с какой-то извращённой формой религии, основанной на фантазиях.

Просто Парамон уже так видимо написал, так понял, не подумав. И теперь хочет оправдать свои деяния.
Ничего страшного, все ошибаются.
Но не все умеют признавать свои ошибки.
...
Рейтинг: 0 / 0
08.10.2018, 15:53
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714491
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
AddxhVostt,

Вы все еще надеетесь убедить логикой и отсылками к документации? )))
Все еще надеемся увидеть от тебя ссылки и примеры с опровержением )
...
Рейтинг: 0 / 0
08.10.2018, 15:53
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714493
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
hVosttПросто Парамон уже так видимо написал, так понял, не подумав. И теперь хочет оправдать свои деяния.
Не хорошо проецировать на меня свои проблемы )
Респонс то покажешь свой, а?
...
Рейтинг: 0 / 0
08.10.2018, 15:55
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714494
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
ПарамонДа, все фантазеры, а ты Дартаньян. )

Ну-ну. Я то на RFC опираюсь, а ты на какого-то Васю из стековерфлоу, который в свободной форме трактует RFC и подменяет понятия, как ему хочется.


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

По какой-то, это какой? Это ошибка протокола, или это ожидаемое поведение? Пользователи ошибаются, договоры бывают в состоянии, которые пользователь изменить не может, товар бывает недоступен и не может быть продан, это НОРМАЛЬНО. Это не ошибка.

Но вам ХОЧЕТСЯ засунуть весь свой бред в какие-то коды.
Ну суйте, я не против.

Деревня, она и в Африке деревня..
...
Рейтинг: 0 / 0
08.10.2018, 15:56
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714498
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
ПарамонhVosttПросто Парамон уже так видимо написал, так понял, не подумав. И теперь хочет оправдать свои деяния.
Не хорошо проецировать на меня свои проблемы )
Респонс то покажешь свой, а?

Пример давай.
...
Рейтинг: 0 / 0
08.10.2018, 15:56
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714499
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
AddxУ него же столько лайков!
Будешь судить других, когда заработаешь хотябы один )
...
Рейтинг: 0 / 0
08.10.2018, 15:57
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714503
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
hVosttПарамонпропущено...

Не хорошо проецировать на меня свои проблемы )
Респонс то покажешь свой, а?

Пример давай.
Вот:
hVosttА если тебе присылают правильно оформленное имя пользователя при регистрации, но оно уже зарезервировано
...
Рейтинг: 0 / 0
08.10.2018, 15:58
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714508
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
hVosttоторый в свободной форме трактует RFC и подменяет понятия, как ему хочется.
Это то, чем ты занимаешься по факту, не приведя ни одной ссылки, а там поддержали сотни разработчиков.
Да и полно инфы на эту тему, уже давно все обсосано, но зачем читать и рушить свой маленький мирок )
...
Рейтинг: 0 / 0
08.10.2018, 16:04
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714516
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
hVosttНу-ну. Я то на RFC опираюсь, а ты на какого-то Васю из стековерфлоу
На стековерфлоу опираются миллионы, больше половины твоих отсылов тут на этот ресурс, но вдруг там стало все плохо. Не хорошо в колодец то плевать )
Я даже перевел 21698262 , но увы, бисером метать устал (
...
Рейтинг: 0 / 0
08.10.2018, 16:11
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714524
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
ПарамонВот:
hVosttА если тебе присылают правильно оформленное имя пользователя при регистрации, но оно уже зарезервировано

например, так

Код: javascript
1.
2.
3.
4.
{
   "model": { "username": "vasya" },
   "errors": { "username": "Имя пользователя уже зарегистрировано" }
}



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

Но куда мне тягаться с "сотней разработчиков", да? ))))
...
Рейтинг: 0 / 0
08.10.2018, 16:17
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714526
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
ПарамонЭто то, чем ты занимаешься по факту, не приведя ни одной ссылк

А вот врать не надо. Я RFC привел, цитаты скинул, выделил уж совсем для детей.


Парамона там поддержали сотни разработчиков.

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


ПарамонДа и полно инфы на эту тему, уже давно все обсосано, но зачем читать и рушить свой маленький мирок )

Фантазёр ты великий. Уже и мир выдумал.
...
Рейтинг: 0 / 0
08.10.2018, 16:19
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714529
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
hVosttтовар бывает недоступен и не может быть продан, это НОРМАЛЬНО. Это не ошибка.
Логично, а кто сказал что тут ошибка? И сообщение будет чисть информативным.
Ошибка это, когда мы хотим и верим, что клиент должен что либо изменить в запросе.
Например попробовать другой ник, в случае когда этот уже зарезервирован.
У тебя явно каша.
...
Рейтинг: 0 / 0
08.10.2018, 16:23
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714535
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
ПарамонНа стековерфлоу опираются миллионы, больше половины твоих отсылов тут на этот ресурс, но вдруг там стало все плохо. Не хорошо в колодец то плевать )
Я даже перевел 21698262 , но увы, бисером метать устал (

Реальные аргументы будут? Что за детский сад с "миллионами", мы что в яслях?
Вроде взрослый дядька.
...
Рейтинг: 0 / 0
08.10.2018, 16:25
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714553
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
hVosttПарамонВот:
пропущено...


например, так

Код: javascript
1.
2.
3.
4.
{
   "model": { "username": "vasya" },
   "errors": { "username": "Имя пользователя уже зарегистрировано" }
}




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


Забавный респонс, сам придумал или надоумил кто? Клиенту нужно эту кашу разбирать, когда можно просто и стандартно:
Код: javascript
1.
2.
3.
4.
5.
6.
7.
8.
9.
$.ajax({
    // ...
    success: function(response) {
   ...
    },
    error: function(xhr, status, text) {
    ...
    }
});


Можно твой код клиента?
hVosttНо куда мне тягаться с "сотней разработчиков", да?
Ну, как бы да ))


hVosttТолку мне от этих сотней разрабов, если я понимаю
Проблема, когда не понимаешь, и вводишь других в заблуждение.
...
Рейтинг: 0 / 0
08.10.2018, 16:38
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714554
Addx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Addx
Участник
ПарамонAddxУ него же столько лайков!
Будешь судить других, когда заработаешь хотябы один )
К счастью, мне платят не за лайки. Я не блоггер.

ПарамонAddxhVostt,

Вы все еще надеетесь убедить логикой и отсылками к документации? )))
Все еще надеемся увидеть от тебя ссылки и примеры с опровержением )

Т.е. ссылок на RFC Вам не достаточно? Нужно на какой-нибудь видеоблог на ютубчике?
Может с котиками лучше? За них столько лайков ставят!

PS
Вы можете использовать любые коды. Никто не запрещает. В целом пользователям будет все равно.
Но аргументировать свою позицию постами и лайками смешно.
...
Рейтинг: 0 / 0
08.10.2018, 16:38
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714556
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
hVosttРеальные аргументы будут? Что за детский сад с "миллионами", мы что в яслях?
Какой вопрос, такой ответ.
...
Рейтинг: 0 / 0
08.10.2018, 16:39
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714562
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
AddxТ.е. ссылок на RFC Вам не достаточно
Было бы достаточно, если бы каждый школьник не трактовал их по своему, искренне веря в свою правоту.

AddxНужно на какой-нибудь видеоблог на ютубчике
Может с котиками лучше? За них столько лайков ставят!
Слив защитан.
...
Рейтинг: 0 / 0
08.10.2018, 16:44
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714563
handmadeFromRu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
handmadeFromRu
Участник
AddxhandmadeFromRu я видел апи того же яндекса и других контор что на ошибку отвечают 200 и меняли дто в ответе либ делали "суперобъект" с заранее заложенными свойствами полями ошибки, вот только зачем.

И действительно, почти все серьезные конторы так делают. Дураки, наверное.

ппфф высер. бот яндекса lastmodified присылает дату (присылал пара лет назад) не в стандарте iso хотя везде написано что надо бы так. я еще могу вспомнить примеры кривости из яндекс доставки и оплаты к примеру. да серьезные конторы эт все боги ...
...
Рейтинг: 0 / 0
08.10.2018, 16:44
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714566
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
ПарамонЗабавный респонс, сам придумал или надоумил кто? Клиенту нужно эту кашу разбирать, когда можно просто и стандартно:
Код: javascript
1.
2.
3.
4.
5.
6.
7.
8.
9.
$.ajax({
    // ...
    success: function(response) {
   ...
    },
    error: function(xhr, status, text) {
    ...
    }
});



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


ПарамонМожно твой код клиента?

Ну не $.ajax точно, реализация store на клиенте в случае REST API,
это по-сложней, чем твои игрульки с jQ ))



AddxНужно на какой-нибудь видеоблог на ютубчике?

После "миллионов" можно уже и блог на ютубчике, давай жги уже, днище пробито ))


ПарамонПроблема, когда не понимаешь, и вводишь других в заблуждение.

Ну куда мне до "миллионов"

И конечно до отлова валидации ввода в error на jq

Лан. Тут тёмный лес понятно. Но мрак конечно знатный, до сих пор в шоке.
Парамон. Ну от тебя не ожидал.
...
Рейтинг: 0 / 0
08.10.2018, 16:49
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714568
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
hVosttAddxНужно на какой-нибудь видеоблог на ютубчике?

После "миллионов" можно уже и блог на ютубчике, давай жги уже, днище пробито ))

Сорян, попутал, меня уже знатно прёт от этого треда ))
...
Рейтинг: 0 / 0
08.10.2018, 16:50
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714569
handmadeFromRu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
handmadeFromRu
Участник
hVostt,

куча высера с переходом на личности даже было лень копипастить
отвечают на твои вопросы просто 409
из rfc7231

The 409 (Conflict) status code indicates that the request could not be completed due to a conflict with the current state of the target resource. This code is used in situations where the user might be able to resolve the conflict and resubmit the request. The server SHOULD generate a payload that includes enough information for a user to recognize the source of the conflict.

и вуаля и админы могут скипать и ты спишь спокойно и даже по стандарту. и все как надо внезапно да?
...
Рейтинг: 0 / 0
08.10.2018, 16:56
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714574
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
hVosttAddxНужно на какой-нибудь видеоблог на ютубчике?

После "миллионов" можно уже и блог на ютубчике, давай жги уже, днище пробито ))


hVosttНу не $.ajax точно, реализация store на клиенте в случае REST API,
это по-сложней, чем твои игрульки с jQ ))
Пытаюсь приводить примеры на пальцах, но ты и тут сути не улавливеашь )
hVosttНу куда мне до "миллионов"
Скромнее будь, глядишь и косяки признавать начнешь )
...
Рейтинг: 0 / 0
08.10.2018, 17:08
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714581
Addx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Addx
Участник
handmadeFromRuппфф высер. бот яндекса lastmodified присылает дату (присылал пара лет назад) не в стандарте iso хотя везде написано что надо бы так. я еще могу вспомнить примеры кривости из яндекс доставки и оплаты к примеру. да серьезные конторы эт все боги ...

Хамство я отставляю на Вашей совести.
С чего Вы взяли, что я считаю серьезные конторы "богами"? Я столько ошибок и проблем с их API поимел, чтобы никаких иллюзий не испытывать.
Но в целом их API грамотнее 90% остальных, с которыми работал. Там вообще труба.
...
Рейтинг: 0 / 0
08.10.2018, 17:18
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714583
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
handmadeFromRuhVostt,

куча высера с переходом на личности даже было лень копипастить
отвечают на твои вопросы просто 409
из rfc7231

The 409 (Conflict) status code indicates that the request could not be completed due to a conflict with the current state of the target resource. This code is used in situations where the user might be able to resolve the conflict and resubmit the request. The server SHOULD generate a payload that includes enough information for a user to recognize the source of the conflict.

и вуаля и админы могут скипать и ты спишь спокойно и даже по стандарту. и все как надо внезапно да?
Уже писали ему 21697192 . Там глухая оборона, и задетое самомнение )
...
Рейтинг: 0 / 0
08.10.2018, 17:18
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714595
monstrU
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
monstrU
Участник
девочки, не ссорьтесь :)

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

Код: html
1.
GET https://demo.edinoepole.ru/api/contractors/v2/events?contractor_id=123



дано
1. идентификатор верного контрагента 123.
2. других контрагентов в тестовом шлюзе нет.

требуется описать вашу архитектуру rest сервиса
1. что вы будете возвращать при вызове контрагента 123 => https://demo.edinoepole.ru/api/contractors/v2/events?contractor_id=123
2. что вы будете возвращать при вызове контрагента 456 => https://demo.edinoepole.ru/api/contractors/v2/events?contractor_id=456
3. что вы будете возвращать при вызове метода https://demo.edinoepole.ru/api/contractors/v2/event?contractor_id=123

один сеанс описывается у них объектом
Код: javascript
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
{
	"id": 52,
	"showtime": "2018-10-08T23:59:00.000+03:00",
	"status": "on_sale",
	"performance_id": 12,
	"hall_id": 11,
	"stop_reservation_time": "2018-10-08T23:44:00.000+03:00",
	"stop_long_reservation_time": "2018-10-08T23:44:00.000+03:00",
	"organization_id": 0
}



просьба сформулировать ваш вариант архитектуры для того, чтобы рассмотреть все возможные варианты и выбрать наилучшие подходы.
просьба первым постом предоставить ваш вариант архитектуры, вторым постом написать, что оппонент ч(М)удак, и далее по тексту.

я предлагаю учитывать, что 100% верного решения не будет и нужно выбрать какие то компромиссы .
...
Рейтинг: 0 / 0
08.10.2018, 17:40
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714598
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
ПарамонПытаюсь приводить примеры на пальцах, но ты и тут сути не улавливеашь )

Ну какие ты примеры "на пальцах" приводишь? Дёрнутый пример вызова $.ajax? Этот?
Ты так тонко шутишь, или в серьёз шпаришь?


ПарамонУже писали ему 21697192 . Там глухая оборона, и задетое самомнение )

Угу, игнор ответа с моей стороны с полными выкладками из RFC, говорит о том, что ты включил школоло-троллинг, ну это слив при чём какой-то позорный и неинтересный.
...
Рейтинг: 0 / 0
08.10.2018, 17:56
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714599
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
Addx,

Хотим авторитетов, ладно. Амазон устроит?

RESTful Error Responses

Для хвоста отдельно выделю:

amazonAmbiguousGrantByEmailAddress : 400 Bad Request
BucketAlreadyExists : 409 Conflict
BucketAlreadyOwnedByYou : 409 Conflict
BucketNotEmpty : 409 Conflict
RestoreAlreadyInProgress: 409 Conflict
UnresolvableGrantByEmailAddress: 400 Bad Request
...


Но правильно конечно у хвоста, это так, глупые школьники на коленке лабают.
Уже даже не важно, во что его макнуть, все равно пахнет розами ))
...
Рейтинг: 0 / 0
08.10.2018, 17:57
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714600
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
handmadeFromRuи вуаля и админы могут скипать и ты спишь спокойно и даже по стандарту. и все как надо внезапно да?

Ты тоже чукча-не-читатель? Я сказал, что если соответствует спецификации протокола, и речь идёт об URL, то 409 подходит. А ты что хочешь сказать? Вы какие-то тёмные ребята.

То "миллионы" каких-то выдуманных адептов непонятно какой религии. То непонятные смыслы.

Что сказать хотите? Приведите противоречие моим словам, хоть одно.
...
Рейтинг: 0 / 0
08.10.2018, 17:59
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714602
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
hVosttТы так тонко шутишь, или в серьёз шпаришь?

Я понимаю, что жить в сумраке так долго это обидно. Смирись.
...
Рейтинг: 0 / 0
08.10.2018, 18:01
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714606
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
hVosttУгу, игнор ответа с моей стороны с полными выкладками из RFC
Смысл? Если ты не в состоянии понять, что там пытались донести ) А я ведь даже перевел.
...
Рейтинг: 0 / 0
08.10.2018, 18:05
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714608
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
ПарамонХотим авторитетов, ладно. Амазон устроит?

RESTful Error Responses

Большие дяди тоже косячат. Примеров подобного составы, у всех.

Ну и криминального тут ничего нет. Просто очередной РЕСТ головного мозга, это бывает как раз в передовых компаниях. И с попыткой внедрить насильно XML в веб было, что теперь? Что это доказывает, я не понимаю?


ПарамонНо правильно конечно у хвоста, это так, глупые школьники на коленке лабают.
Уже даже не важно, во что его макнуть, все равно пахнет розами ))

Я пока вижу только попытки прикрыться авторитетами. Это всё, что я увидел.
...
Рейтинг: 0 / 0
08.10.2018, 18:05
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714609
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
hVosttБольшие дяди тоже косячат. Примеров подобного составы, у всех
Stakoverflow комьюнити косячат, Amazon, MS косячат.
Вам кажется, что все вокруг дураки?
Это давно началось?


hVosttЯ пока вижу только попытки прикрыться авторитетами. Это всё, что я увидел.
Хотя бы, я так вообще ничего, кроме неправильного понимания RFC не увидел )
...
Рейтинг: 0 / 0
08.10.2018, 18:12
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714611
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
Мдааааа, развели срач...

Что полезного-то в итоге? То, что пора звать модератора?
...
Рейтинг: 0 / 0
08.10.2018, 18:14
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714616
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
skyANAЧто полезного-то в итоге?
Это очевидно.

Ответ на вотпрос автора и выводы:

1. Стандартный подход есть.
2. Для каждого респонса используем подходящий стандартный статус. Особенно это касается ошибок клиента.
3. Статус 200 + ошибка - сразу в сад.
...
Рейтинг: 0 / 0
08.10.2018, 18:20
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714617
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
ПарамонStakoverflow комьюнити косячат, Amazon, MS косячат.
Вам кажется, что все вокруг дураки?
Это давно началось?

Если ты без дядей не можешь пояснить почему надо так, а не иначе, то у меня для тебя плохие новости.
Авторитеты, популярность это хорошо, надо использовать эту информацию, но 100% всё на этом строить, ты уж извини.
Не серьёзно.


ПарамонХотя бы, я так вообще ничего, кроме неправильного понимания RFC не увидел )

Там всё чётко написано, это описание протокола.
Ошибки нужно уметь мониторить без знания содержания ответов и их внутренних специфичных форматов.
50 штук Bad Request как отделять бизнес от реальных ошибок?
Расскажи это админам и потыч им в лицо амазоном и "миллионами", они тебя нафиг пошлют.

Я вижу до сих пор полное непонимание смысла и назначения кодов ошибок HTTP с твоей стороны и со стороны handmadeFromRu.

Так-то можно всегда 500 отдавать и клиента научить не париться. Чё такого.
...
Рейтинг: 0 / 0
08.10.2018, 18:21
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714618
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
skyANAТо, что пора звать модератора?
Можно закрывать имхо.
...
Рейтинг: 0 / 0
08.10.2018, 18:21
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714619
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
Парамон1. Стандартный подход есть.

Есть, но ты его не применяешь.


Парамон2. Для каждого респонса используем подходящий стандартный статус. Особенно это касается ошибок клиента.

Подходящий, это на что получится натянуть?


Парамон3. Статус 200 + ошибка - сразу в сад.

Непонимание термина "ошибка".
...
Рейтинг: 0 / 0
08.10.2018, 18:22
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714621
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
hVosttЕсли ты без дядей не можешь пояснить почему надо так, а не иначе, то у меня для тебя плохие новости.
Объяснял, не помогло, Авторитеты тоже не помогли. Вот это плохие новости. Безнадега (

hVosttЯ вижу до сих пор полное непонимание смысла и назначения кодов ошибок HTTP с твоей стороны и со стороны handmadeFromRu
Мы уже поняли, успакойся, глубокий вздох.
...
Рейтинг: 0 / 0
08.10.2018, 18:26
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714624
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
hVosttНепонимание термина "ошибка".
Несоответствие между запросом клиента и ожиданием сервера.
Сколько раз еще повторить? Или у тебя опять альтернативное мнение?
Уже по ложечке кормлю.
...
Рейтинг: 0 / 0
08.10.2018, 18:38
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714625
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
hVosttПодходящий, это на что получится натянуть?
Не надо натягивать, все стандартно, расфасовано по категориям.
...
Рейтинг: 0 / 0
08.10.2018, 18:40
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714635
handmadeFromRu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
handmadeFromRu
Участник
Addx,
да я вроде не хамил ты что то путаешь. а вот намек на дураков с твой слов как раз хамство

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

п.с. начни писать нормально без перехода на личности. Вроде умный человек, а ведешь себя как истеричка.
п.с. п.с. если ты считаешь что ты как то сильно аргументировал, то ты ошибаешься.
...
Рейтинг: 0 / 0
08.10.2018, 18:54
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714638
Агнец за бортом
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Агнец за бортом
Участник
Парамон3. Статус 200 + ошибка - сразу в сад.

Только недавно проскакивал на работе пример, что сервер вернул ответ, где errorID == 0.

И это типа "ошибок нет". А на самом деле - ошибка есть. А что и кто имел ввиду?

На вопрос почему не возвращать стандартные http-коды - хлопанье глазами.

Гораздо лучше ветвить логику a la:

1. errorID>0 - ошибка
2. errorID==0 нет ошибки
3. errorID==0 ошибка как бы есть, но её нет, надо пошурудить в контексте.
3. errorID==0 ошибки как бы нет, но она есть, надо пошурудить в контексте.
4. Ну и напрашивается errorID>0 - ошибка есть, ну и фиг с ней.

Еще и завязаться на состояние сервере * состояние клиента - и назвать это "ребят, ну тут вещь посерьезнее $.ajax()"

К слову, $.ajax - не отличается от библиотеки к библиотеке.

Сила в простоте. А стандарт для стандарта поверх стандарта - это уже деформация. Профессиональная.
...
Рейтинг: 0 / 0
08.10.2018, 18:59
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714643
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
hVosttЕсть, но ты его не применяешь.
Применяю! ))
Аргументы хвоста скатились на уровень - "сам дурак"
...
Рейтинг: 0 / 0
08.10.2018, 19:09
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714649
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
Парамон,

А чё тогда столько слов, воздыхания и размахивание руками?

И на личности вы уже перешли, и не поморщились.

Аргументы то где?

Посмотри у Амазона.... Ясно. Я ещё раз объясню, как приеду. Но явно не для вас. Почему-то
по этой теме вы не способны аргументировано вести диалог. Понятия не имею с чем это связано.
...
Рейтинг: 0 / 0
08.10.2018, 19:24
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714663
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
С самого начала я говорил, разделяйте ошибки протокола и ошибки приложения. Это разные вещи.

Зачем это нужно? Ничего нового, разделяй и властвуй.
Если вы в кучу навалите ошибки протокола (взаимодействия) и ошибки логики приложения, от этого вообще никакой пользы не будет. Вообще. Явного вреда конечно тоже, но тогда смысла в нумерации кодов никакого нет.

Давайте на примере ошибки 400 Bad Request.

Когда клиент делает запрос на сервер, а в ответ получает код 400, значит что-то он делает не так. Не пользователь, а приложение-клиент.

Это может быть:

-- неправильный тип содержимого запроса
-- неправильный формат содержимого
-- не соответствие типа и содержимого
-- ошибка формата (похеренное содержимое, или неправильно составленный запрос)
-- неправильные заголовки
-- и т.д.

Чем может помочь код 400?
Для приложения клиента: информация, об ошибке приложения клиента, или канала доставки (прокси, промежуточное ПО и т.д.).
Для приложения сервера: явный маркер о том, что приложение клиента работает неправильно.

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

Это полезно. Мониторинг собирает статистику таких нарушений, при чём совершенно не зная подробностей реализации клиента и сервера, по методу чёрного ящика.

В реализации клиента, полученный ответ 400 явно означает, что запрос сформирован не верно.

Но давайте отбросим эти рассуждения. Просто посмотрим на тип ошибки "Bad Request". Это же "Плохой запрос"! Значит, если приложение пытается

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

это же всё "Плохой запрос"! Будем отдавать ответ любого запроса, который приложению "не понравился", с кодом ошибки 400. А почему нет? Можно так сделать.

Но как только мы так сделаем, мы потеряем все преимущества мониторинга "черного ящика", код 400 по существу нам теперь вообще ни о чём не говорит. Это просто КАКАЯ-ТО ошибка. Ну да, вы можете пройти на страницу документации и посмотреть каким проблемам назначен этот код, плюс ко всем реальным ошибкам плохого запроса. Чтобы хоть что-то понятно, надо анализировать содержимое ответа.

Т.е. стало хуже. Пользы никакой от попытки распихать ответы с проблемами, о которых приложение хочет сообщить клиенту по списку доступных кодов нет. Совершенно никакой.

С точки зрения реализации клиента, подумайте, какова будет логика обработки ответа?

error:
if (400)
if (это ошибка протокола? клиент накосячил?)
else (это проблема валидации?)
else ....

О технике нормальной обработки ошибок на хуках можно забыть.

Я конечно не д.Артаньян, всё верно. И не Амазон. И не вымышленный "миллион" гениев. Но у меня есть обоснованные, понятные аргументы, построенные на логике, понимании разницы, и RFC.

А сделать можно как угодно. Можно вообще использовать два кода: 200 и 500. Это тоже будет работать. Даже чистый 500 для всех ответов, даже нормальных -- будет работать.

Но кто уже НАКОСЯЧИЛ и тупо "подогнал" нормальные ответы логики под коды ошибок HTTP будет и дальше до посинения тут нести чушь про Амазоны и не аргументировать больше ничем.

Читайте RFC, думайте головой, а не ж...й.

П.С. Меня реально очень неприятно удивило, что такие грамотные спецы как Парамон и хэндмейд могут на такой хрени нести ахинею. Вот даже не буду ничё писать, просто, гонят они, а стыдно за них мне.
...
Рейтинг: 0 / 0
08.10.2018, 20:16
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714672
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
hVostt,

Всего лишь поддерживаю стиль общения собеседника, но в своём глазу ведь бревно не видно.
У моих доводов есть поддержка авторитетов и комьюнити. У твоих нет. Это тоже аргумент и факт.
А трактовать RFC так, как тебе удобно не проходит за аргумент.
Ты называешь это не думать головой, а я - брать на вооружение успешный подход, и не изобретать велосипед на ровном месте.
Твой подход путает разработчиков, аргумент 2, пример выше.
Каждый придумывает свой респонс, нет стандартного, аргумент 3.
Клинт сразу понимает, что ошибся и в каком направлении, аргумент 4.
Дальше слушаем твои.
...
Рейтинг: 0 / 0
08.10.2018, 20:54
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714676
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
hVostt,
Все это деление на протокол и логику надуманно.
Разделить, что длинна поля не правильна, или число не логично с точки зрения бизнес вычислений, не даёт никого профита. Но возвращать при этом разный статус, реально запутает.
...
Рейтинг: 0 / 0
08.10.2018, 21:08
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714679
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
hVostt,

С точки зрения клиента все намного проще.
Я уже приводил пример с ajax.
Не нужно ему пудрить, это 200 но с ошибками, а то 400 но поле длинное.
...
Рейтинг: 0 / 0
08.10.2018, 21:17
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714757
monstrU
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
monstrU
Участник
hVostt,

ты извини, но в чем твой подход я не очень понял - больно много написал. можешь внятно сформулировать?
...
Рейтинг: 0 / 0
09.10.2018, 09:15
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714825
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
ПарамонВсего лишь поддерживаю стиль общения собеседника, но в своём глазу ведь бревно не видно.

Какой-то детский сад. Если ты уже перешёл на личности, изволь не обвинять собеседника.
А то ощущение, что тебе 10 лет, ты ещё скажи "он первый наааачал".


ПарамонУ моих доводов есть поддержка авторитетов и комьюнити. У твоих нет. Это тоже аргумент и факт.

Нет никакой поддержки. Да и доводов по сути ни каких нет. Вообще.


ПарамонА трактовать RFC так, как тебе удобно не проходит за аргумент.

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

А у тебя, извини, какие-то больные фантазии. Не более того.
Да ещё попытки подтянуть вымышленные миллионы.


ПарамонТы называешь это не думать головой, а я - брать на вооружение успешный подход, и не изобретать велосипед на ровном месте.

Ты именно этим занимаешься. Фантазируешь, изобретаешь велосипед.

ПарамонТвой подход путает разработчиков, аргумент 2, пример выше.

В чём путает? Ты чё придумываешь?

ПарамонКаждый придумывает свой респонс, нет стандартного, аргумент 3.

Вот оно. Если если по-твоему каждый придумывает свой респонс ,
о чём тогда вообще речь?

ПарамонКлинт сразу понимает, что ошибся и в каком направлении, аргумент 4.

Ты получил код 400. Что ты из этого понял?

Если следовать RFC, и разделять ошибки протокола и логики, то 400 это явно ошибка в реализации клиента. Это гарантия.

Что в твоём понимании? Надо для каждого случая изучать респонс, чтобы понять где проблема? Да ещё для каждого приложения надо свой формат респонза изучать?

Твои аргументы не убедительны от слова совсем, да ещё основаны на каких-то фантазиях.
...
Рейтинг: 0 / 0
09.10.2018, 11:42
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714826
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
ПарамонВсе это деление на протокол и логику надуманно.

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



Я же говорил. Детский сад и поле чудес. Тебе надо на форум модников и фломастеров.
...
Рейтинг: 0 / 0
09.10.2018, 11:43
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714848
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
monstrUhVostt,

ты извини, но в чем твой подход я не очень понял - больно много написал. можешь внятно сформулировать?
В двух словах. Если клиент ошибся с бизнес логикой, то сервис хвоста вернёт статус 200 и сообщение с ошибкой. Все.
Много буков он выдаёт, да бы отстоять свою позицию плюс нервишки шалят. ))
...
Рейтинг: 0 / 0
09.10.2018, 12:13
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39714918
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ViPRos
Участник
При ошибках логики надо возвращать статус 402 :)
(А так хвост прав - 200 и все дела - HTTP сработал как положено)
...
Рейтинг: 0 / 0
09.10.2018, 14:11
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715228
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
ПарамонВ двух словах. Если клиент ошибся с бизнес логикой, то сервис хвоста вернёт статус 200 и сообщение с ошибкой. Все.

В двух словах: HTTP, который используется для общения приложений клиента и сервера -- это всего лишь протокол. Ошибки HTTP предназначены для работы протокола, а не для логики приложений.


ПарамонМного буков он выдаёт, да бы отстоять свою позицию плюс нервишки шалят. ))

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

Позиция у меня абсолютно железная.

Ты ещё предложи использовать исключения в C# для передачи обычных сообщений внутри логики.
Это по сути абсолютно тоже самое.
...
Рейтинг: 0 / 0
09.10.2018, 23:20
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715232
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
ViPRosПри ошибках логики надо возвращать статус 402 :)
(А так хвост прав - 200 и все дела - HTTP сработал как положено)

Всё верно. Любые коды ошибок с точки зрения HTTP означают проблемные ситуации, они мониторятся, по ним собираются статистика и генерятся репорты.

И потом, я ещё не раскрывал тему с точки зрения тестирования.
Но учитывая мрак в головах, думаю это бессмысленно.
...
Рейтинг: 0 / 0
09.10.2018, 23:23
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715274
stenford
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
stenford
Участник
ПарамонРазделить, что длинна поля не правильна, или число не логично с точки зрения бизнес вычислений, не даёт никого профита. Но возвращать при этом разный статус, реально запутает.
+1 В этом и состоит разница между нагугленным опытом, и практическим
...
Рейтинг: 0 / 0
10.10.2018, 00:44
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715382
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
stenford,

Вы это админам объясните, что вы в 400 будете бизнесовые кейсы засовывать.
Потом объясните группе тестирования что им надо ещё коды ошибок протокола тестировать.

А потом, когда попросят прислать вместо вам адекватного разработчика, пожалуйтесь про нагугленный опыт.
...
Рейтинг: 0 / 0
10.10.2018, 09:31
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715408
handmadeFromRu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
handmadeFromRu
Участник
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 просто пишется об ошибке клиента с точки зрения веб-приложения

п.с. оффтом не по теме - ты хоть не много задумывался что можешь быть не правым? вот иногда ? да не бред ж это хвост он не ошибаешься
...
Рейтинг: 0 / 0
10.10.2018, 10:25
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715431
handmadeFromRu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
handmadeFromRu
Участник
ладно хвост тут больше делать нечего.
мы уже поняли друг друга, я дурак для тебя и прочее.
давай лучше как нить под пивко такое дискутировать)
...
Рейтинг: 0 / 0
10.10.2018, 10:52
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715434
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
handmadeFromRuп.с. оффтом не по теме - ты хоть не много задумывался что можешь быть не правым? вот иногда ? да не бред ж это хвост он не ошибаешься
Мало кто может публично заявить, что сглупил. И не переписывать же теперь все свои сервисы. А как с этим жить?
Нет смысла дальше спорить и доказывать очевидное.
...
Рейтинг: 0 / 0
10.10.2018, 10:59
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715438
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
handmadeFromRuзачем мне админам что то объяснять? логи ошибок они проанализирую в ролбаре или в elk туда и попадет 400 стандартная. 400 от бизнес уровня туда не попадут.

затем, что твои логи это твои логи. то, что ты туда напишешь -- твоё дело.

именно поэтому, с точки зрения администрирования, админу важны выделить работает твоё приложение хорошо, или есть ошибки, при чём БЕЗ знания подробностей реализации. на твои форматы сообщений JSON/XML мониторингу положить, никто не будет в большой экосистеме из кучи сервисов и приложений ковырять и разделять ошибки протокольного уровня от нормальных бизнес-кейсов.


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

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

а если важен, то уже блин напишите почему?
только без детского лепета про амазон и "миллионы" адептов.
скажи, нафига тебе в 400 засовывать отдельные бизнес сценарии?
или в другой код HTTP ошибки?

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

для чего эту кашу создавать? ради какой великой цели?

просто я не понимать.




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

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

ну вот добей меня, скажи, что это безаппеляционный аргумент.
я тогда вообще ничё писать не буду. нафиг надо.
спорить с какими-то "миллионами" в лице одного человека, это тухлый номер.
...
Рейтинг: 0 / 0
10.10.2018, 11:12
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715440
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
ПарамонМало кто может публично заявить, что сглупил. И не переписывать же теперь все свои сервисы. А как с этим жить?
Нет смысла дальше спорить и доказывать очевидное.

Ни о чём. Я указываю на конкретные задачи и проблемы, от вас только неадекватные смешки и бесполезный трёп.
...
Рейтинг: 0 / 0
10.10.2018, 11:13
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715454
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
handmadeFromRuстандарт http ничего не говорит о типе приложения
только о протоколе общения между клиентом и сервером
но... веб-сервер и веб-приложение - это две части одного целого
и то, и другое работают вместе, чтобы подготовить ответ
поэтому, 400 в случае ошибки в бизнес-логике - это нормально, и это ожидаемо

С хрена ли? А если приложение будет работать и через REST API, и через, например, веб-сокет, или интеграция через JRPC, и т.п. -- ты что, потащишь свои HTTP коды ошибок во все остальные протоколы?

Я не понимаю, с какого хрена смешивание протокола и бизнес-логики это вдруг стало нормальным?
С каких пор это ожидаемо? Где об этом написано?
В RFC я не нашёл, если буквоедством заниматься. Там написано чёрным по белому примеры, когда применяется тот же код 400.

Это явная проблема контракта. Bad Request -- это плохо составленный запрос, невозможно продолжить коммуникацию с таким запросом. На уровне протокола.

Если как ты говоришь про "ожидаемо", тогда можно говорить о том, что можно использовать любой код для любых целей какой заблагорассудится разработчику. Так?
...
Рейтинг: 0 / 0
10.10.2018, 11:24
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715488
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
Ладно, продолжим. ))
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Я указываю на конкретные задачи и проблемы, от вас только неадекватные смешки
Извени, кроме смеха твои проблемы и задачи ничего не вызывают. )
...
Рейтинг: 0 / 0
10.10.2018, 12:05
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715493
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
hVostt,

Скажи про "402 Payment Required" платеж это бизнес логика или ошибка протокола?? )
...
Рейтинг: 0 / 0
10.10.2018, 12:10
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715496
Addx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Addx
Участник
skyANAМдааааа, развели срач...

Что полезного-то в итоге? То, что пора звать модератора?

Модератора-то за что? :))
...
Рейтинг: 0 / 0
10.10.2018, 12:12
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715499
Addx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Addx
Участник
ПарамонhVostt,

Скажи про "402 Payment Required" платеж это бизнес логика или ошибка протокола?? )

Это код, который ни один нормальный разработчик использовать не будет.
...
Рейтинг: 0 / 0
10.10.2018, 12:14
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715500
Фотография Shocker.Pro
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shocker.Pro
Участник
ПарамонСкажи про "402 Payment Required" платеж это бизнес логика или ошибка протокола?? )Если забыл заплатить за протокол - то ошибка протокола ))
...
Рейтинг: 0 / 0
10.10.2018, 12:15
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715501
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
Shocker.ProПарамонСкажи про "402 Payment Required" платеж это бизнес логика или ошибка протокола?? )Если забыл заплатить за протокол - то ошибка протокола ))
...
Рейтинг: 0 / 0
10.10.2018, 12:16
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715523
handmadeFromRu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
handmadeFromRu
Участник
hVostt,

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

вообщем я херачу 400 + тело, ты 200 + тело. мы все довольны. зачем писать только что мы тупые не пойму. почему бы не написать "я считаю так то и так ...". у меня больше кипит что ты всех налево и направо называешь тупыми и мы типо не читаем.
я подчеркиваю я использую такой подход прочитав rfc, а не амазон, и считаю http часть приложения (rfc7231 это явно описывает прямо в начале текста) а значит протокол должен отражать ошибку явно. у меня все.
...
Рейтинг: 0 / 0
10.10.2018, 13:05
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715557
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
ПарамонРасписанно не все, а только основные принципы. Никогда сухое описание стандарта не обходит все кейсы, для более глубокого понимания обычно пишут книги, блоги и тд. Ты просто описываешь тут свое понимание, то есть непонимание, а копнуть глубже не в состоянии.

Демагогия какая-то. Все-не все. RFC это стандарт. Давай книги приводи тогда, источники, если сам не в состоянии объяснить что ты делаешь и почему. Не проблема.


ПарамонК примеру 5xx говорит о другом, 200 говорит "ОК". заметь, "ок, ты ошибся" - звучит глупо

ОК говорит, что запрос успешно принят и обработан. Всё. Он не говорит о том, что у клиента есть деньги на счету для оплаты заказа, а если нет, он что получить должен? 400? 404?

С логикой продолжаем не дружить?


ПарамонЕсть категории, и стандартные коды, ответ 200 на все случаи жизни это детсад какой то.

Ты пояснить можешь? Вижу, что пока не можешь.
Чем тебя 200 ОК не устраивает для случаев, когда приложение возвращает ответ, который понял и обработан логикой. В чём проблемы?

В внутри кода, ты тоже коды прокидываешь?

Тебя прямо спрашивают, ты захрена запихал вот в этот ответ код 400?
Ты что ответишь? Амазоном прикроешься? Не находишь, что это идиотия?


ПарамонЛед попробуй или мороженку.

Тролль из тебя унылый.


ПарамонРазумеется, конечно если уровень тестировщикав выше плинтуса, то они должны понимать коды ошибок.

Серьёзно? Ошибки 500 тестируете? Сколько кейсов на бэд реквест? Пихаете XML туда, где ожидаю JSON? Подаёте тысячу вариантов неправильного JSON?


ПарамонИзвени, кроме смеха твои проблемы и задачи ничего не вызывают. )

Ну-ну. Ничего зазорного в том, что ты смеёшься, сидя в луже нет. Какие ещё дразнилки продемонстрируешь?
...
Рейтинг: 0 / 0
10.10.2018, 13:50
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715563
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
ПарамонhVostt,

Скажи про "402 Payment Required" платеж это бизнес логика или ошибка протокола?? )

Протокольный уровень. Универсальный код ошибки позволяет абстрагироваться от формата содержимого, и как в случае 403, бросить на экран/страницу оплаты, с точки зрения мониторинга тоже всё прозрачно.
...
Рейтинг: 0 / 0
10.10.2018, 13:53
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715570
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
handmadeFromRuя уже все написал и аргументы что ты считаешь туфтой, как и я твои.
все что я напишу дальше также будет подвержено критике и ты никогда не согласишься.

Какая-то демагогия.
Я вам по существу с Парамоном, вы как всегда "о вечном". Ну и хрен с вами.


handmadeFromRuвообщем я херачу 400 + тело, ты 200 + тело. мы все довольны.

О чём тогда разговор? Кто-то опять форумом ошибся и думает, что это раздел моды, и типа надо делать как нравится, все фломастеры разные, а есть модные тенденции?

Доволен? Счастлив за тебя. НАфига влез в дискуссию, если сам говоришь, что пофигу?


handmadeFromRuзачем писать только что мы тупые не пойму. почему бы не написать "я считаю так то и так ...". у меня больше кипит что ты всех налево и направо называешь тупыми и мы типо не читаем.

Ой, какие нежные. Вменяемых аргументов от вас не выпросишь, как рубль у еврея. А как что-то не так сказали в вашу сторону так разобиделись.

Если проблема ток в этом, ок. Уж прастите, больше не буду


handmadeFromRuя подчеркиваю я использую такой подход прочитав rfc, а не амазон, и считаю http часть приложения (rfc7231 это явно описывает прямо в начале текста) а значит протокол должен отражать ошибку явно. у меня все.

В чем польза от того. что ты смешаешь свои сценарии с реальными ошибками протокола?
ПРосто можешь пояснить?
Или ограничишься "я считаю"?
...
Рейтинг: 0 / 0
10.10.2018, 14:01
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715578
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
hVosttОК говорит, что запрос успешно принят и обработан. Всё. Он не говорит о том, что у клиента есть деньги на счету для оплаты заказа, а если нет, он что получить должен? 400? 404?
Открой для себя новый код - 402 Payment Required. Да и вообще пройтись по статусам не помешает, а то выучил 200 и типа все, больше не нужно.
А на все остальное говори так:
AddxЭто код, который ни один нормальный разработчик использовать не будет.
hVosttЧем тебя 200 ОК не устраивает для случаев, когда приложение возвращает ответ, который понял и обработан логикой . В чём проблемы?
Тут могла быть ошибка, и тогда вменяемый сервис вернет 4xx.
hVosttСерьёзно? Ошибки 500 тестируете? Сколько кейсов на бэд реквест? Пихаете XML туда, где ожидаю JSON? Подаёте тысячу вариантов неправильного JSON?
Разумеется, тестируют максимум возможных кейсов от клиента, и возврат правельных статусов.
501 not implemented давольно частый случай, когда еще не весь функционал реализован и клиент должен об этом знать.
Добро пожаловать в первый класс
hVosttПротокольный уровень. Универсальный код ошибки позволяет абстрагироваться от формата содержимого, и как в случае 403, бросить на экран/страницу оплаты, с точки зрения мониторинга тоже всё прозрачно.
Как уж на сковородке, все смеются уже. Просто скажи - оплата в твоем монимании это теперь уровень протокола и твой сервис вернет "200 + извините, вы не заплатали". )) Ты ведь так прямо и написал в преидущем посте.
Ну или забыл заплатить за протокол, тогда 402
...
Рейтинг: 0 / 0
10.10.2018, 14:23
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715591
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
hVosttАмазоном прикроешься

ps
Как бы практика серьезных, мировых лидеров в этой области заслуживает внимания, в отличае от форумных Д’Артаньянов.
...
Рейтинг: 0 / 0
10.10.2018, 14:46
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715636
handmadeFromRu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
handmadeFromRu
Участник
hVostt,
я тебе уже объяснил что по последнему rcf http трактуют как протокол уровень приложения, так как это уровень приложения он должен показывать состояние, там четко написано что 400 это ошибки клиента и не важно какие. это прям написано в документе. аргумент прям из твоего же источника раз ты другое не воспринимаешь.
вот мои аргументы из всех моих постов
1. на основе rfc http часть приложения а значит должно отражать его состояние в конкретный момент времени
2. я могу тестировать апи и понимать что запрос не прошел крайне просто
3. я не вижу проблемы для админов ну ответили мы 400 и? статистика по 400 ответам да нахера она мне нужна. статиска ошибок по логам в elk вот эт я понимаю что то серьезное и что и как и почему.
4. я не вижу проблемы для тестеров если они будут тестить ui так как не важно какой клиент он легко обработает без свистопляски вокруг а может там ошибка все таки вместо объекта

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

>Ой, какие нежные
причем тут нежные? мне не нравиться общаться с человеком который считает нормальным через слово говорить оппоненту что он дурак. хвост я за время дисскусии с тобой ни разу не посмел тебя назвать дураком или еще что то, так почему ты позволяешь себе это?
твоя же аргументация ..лалалалал дебилы..лалалалла да вы упоротные...лалалалала головой не думают (текст приблизительный но суть отражает)
...
Рейтинг: 0 / 0
10.10.2018, 16:13
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715641
Addx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Addx
Участник
handmadeFromRu,

404 - это ошибка протокола (неверный адрес) или ошибка на уровне бизнес-логики (адрес правильный, но данных нет)?
...
Рейтинг: 0 / 0
10.10.2018, 16:18
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715652
handmadeFromRu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
handmadeFromRu
Участник
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...прослеживает четкое изменение. раньше было жестко да щас изза сплошного спа и реста уже не так
...
Рейтинг: 0 / 0
10.10.2018, 16:34
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715654
handmadeFromRu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
handmadeFromRu
Участник
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
...
Рейтинг: 0 / 0
10.10.2018, 16:40
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715657
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
AddxhandmadeFromRu,

404 - это ошибка протокола (неверный адрес) или ошибка на уровне бизнес-логики (адрес правильный, но данных нет)?
Ты ветку читаешь вообще?
Ссылку на примеры от MS открыть в состоянии или их сюда перепечатать?
...
Рейтинг: 0 / 0
10.10.2018, 16:45
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715661
Addx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Addx
Участник
handmadeFromRu,

тут уже начали говорить "по понятиям", а не по RFC.
А именно о "практике мировых лидеров". )))
Уж определитесь тогда, что берете за основу.
Я, собственно, конкретный вопрос задал.
Что вернется в одном, и что в другом случае?
...
Рейтинг: 0 / 0
10.10.2018, 16:54
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715669
handmadeFromRu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
handmadeFromRu
Участник
Addx,
я хз кто там по понятиям но я пытаюсь вести диалог в человеческом русле.
за основу беру то на что хвост меня и направил а именно современный стандарт rfc.
и он стал гибче напорядок.
я ответил текстом текущего стандарта и как было. если делать по текущему стандарту rfc то будет 404.
и заметь - это не мое желание это стандарт.
лет 5 назад я б сказал что хвост все правильно говорит, но и стандарт был другим раньше, щас он стал гибче.
...
Рейтинг: 0 / 0
10.10.2018, 17:04
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715671
Addx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Addx
Участник
ПарамонТы ветку читаешь вообще?
Ссылку на примеры от MS открыть в состоянии или их сюда перепечатать?

Т.е. аргументов у Вас нет?
Вы даже не вникли в то, о чем там речь идет. Не посмотрели название статьи. Вас не смутило "For example, ..."
По сути сложно спорить с людьми, которые не могут аргументировать свою позицию.

И на "Вы" , пожалуйста.
...
Рейтинг: 0 / 0
10.10.2018, 17:06
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715675
Addx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Addx
Участник
handmadeFromRu,

Я понял, по RFC.
Но все же, у меня два разных случая.
Хотелось бы знать ответ для одного и для другого.
...
Рейтинг: 0 / 0
10.10.2018, 17:13
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715686
love_bach
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
love_bach
Участник
Addx404 - это ошибка протокола (неверный адрес) или ошибка на уровне бизнес-логики (адрес правильный, но данных нет)?

вот читаю дискуссию, и пока в сомнениях... мне ближе "неверный адрес". но Хвост говорил выше - что это одно и тоже. а я Хвосту верю :)
...
Рейтинг: 0 / 0
10.10.2018, 17:31
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715698
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
AddxПарамонТы ветку читаешь вообще?
Ссылку на примеры от MS открыть в состоянии или их сюда перепечатать?

Т.е. аргументов у Вас нет?
Вы даже не вникли в то, о чем там речь идет. Не посмотрели название статьи. Вас не смутило "For example, ..."
По сути сложно спорить с людьми, которые не могут аргументировать свою позицию.

И на "Вы" , пожалуйста.
Сложно говорить с людьми, которые совсем не в теме.
Вот этот код хорошо видно?
Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
public Product GetProduct(int id)
{
    Product item = repository.Get(id);
    if (item == null)
    {
        var resp = new HttpResponseMessage(HttpStatusCode.NotFound)
        {
            Content = new StringContent(string.Format("No product with ID = {0}", id)),
            ReasonPhrase = "Product ID Not Found"
        };
        throw new HttpResponseException(resp);
    }
    return item;
}



Ты что спросил?

Addx404 - это ошибка протокола (неверный адрес) или ошибка на уровне бизнес-логики (адрес правильный, но данных нет)?

Теперь я медленно перевожу. В этом коде, 404 возвращают когда (внимание!) нет данных.
Настоятельно советую ознакомится с предметкой.

Пояснения для новичков:

== оператор равенства.
Приравнивание item == null значит данных нет.
HttpStatusCode.NotFound это 404, читаем доку.
...
Рейтинг: 0 / 0
10.10.2018, 17:53
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715702
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
AddxВы даже не вникли в то, о чем там речь идет. Не посмотрели название статьи. Вас не смутило "For example, ..."

Перевожу:

Обработка исключений в asp.net web api.
Что в этом загаловке тебе не ясно?
Да, мы тут все это время говорили об сключениях.
Пример это лучшее наглядное пособие, по этому не смутило.

А что смутило тебя?
...
Рейтинг: 0 / 0
10.10.2018, 18:01
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715705
Addx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Addx
Участник
ПарамонСложно говорить с людьми, которые совсем не в теме.
Вот этот код хорошо видно?
Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
public Product GetProduct(int id)
{
    Product item = repository.Get(id);
    if (item == null)
    {
        var resp = new HttpResponseMessage(HttpStatusCode.NotFound)
        {
            Content = new StringContent(string.Format("No product with ID = {0}", id)),
            ReasonPhrase = "Product ID Not Found"
        };
        throw new HttpResponseException(resp);
    }
    return item;
}



Ты что спросил?

Addx404 - это ошибка протокола (неверный адрес) или ошибка на уровне бизнес-логики (адрес правильный, но данных нет)?

Теперь я медленно перевожу. В этом коде, 404 возвращают когда (внимание!) нет данных.
Настоятельно советую ознакомится с предметкой.

Пояснения для новичков:

== оператор равенства.
Приравнивание item == null значит данных нет.
HttpStatusCode.NotFound это 404, читаем доку.

Если Вы думаете, что хамство усиливает Вашу позицию, то Вы ошибаетесь.
Это говорит исключительно о характере человека.
Увы, базовые операторы языка - это еще не все.
То, что Вы знаете синтаксис C#, это, конечно, неплохо.
А вот с пониманием статьи - о чем она, что, зачем, и почему там так делается у Вас хуже.
...
Рейтинг: 0 / 0
10.10.2018, 18:05
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715709
Addx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Addx
Участник
ПарамонА что смутило тебя?


Лично меня ничего не смутило. А должно было?
Статья об обработке исключений в Web API.
Абсолютно стандартная страница из документации.
...
Рейтинг: 0 / 0
10.10.2018, 18:11
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715710
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
AddxУвы, базовые операторы языка - это еще не все.
То, что Вы знаете синтаксис C#, это, конечно, неплохо.
Правильно, знать синтаксис, неплохо для начала.

AddxА вот с пониманием статьи - о чем она, что, зачем, и почему там так делается у Вас хуже.
Там нечего объяснять, уровень 1 + 1. Но ты попробуй, а то все время это я.
...
Рейтинг: 0 / 0
10.10.2018, 18:13
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715712
Addx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Addx
Участник
ПарамонAddxУвы, базовые операторы языка - это еще не все.
То, что Вы знаете синтаксис C#, это, конечно, неплохо.
Правильно, знать синтаксис, неплохо для начала.

AddxА вот с пониманием статьи - о чем она, что, зачем, и почему там так делается у Вас хуже.
Там нечего объяснять, уровень 1 + 1. Но ты попробуй, а то все время это я.

Насчет Вас я уже все понял, хамите дальше.
Кому-нибудь другому.
Тут много людей, с которыми можно подискутировать без откровенного хамства с их стороны.
...
Рейтинг: 0 / 0
10.10.2018, 18:17
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715713
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
AddxСтатья об обработке исключений в Web API.
Абсолютно стандартная страница из документации.

Ок, первый шаг сделан.

Теперь экзамен.
Какой статус вернет сервис в случае, когда продукт не найден в базе данных?
...
Рейтинг: 0 / 0
10.10.2018, 18:18
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715715
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
AddxТут много людей, с которыми можно подискутировать без откровенного хамства с их стороны.
Всегда забавляют такие.
Говорят по хамски, ответил так же, обижаются.
...
Рейтинг: 0 / 0
10.10.2018, 18:23
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715722
love_bach
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
love_bach
Участник
ПарамонAddxСтатья об обработке исключений в Web API.
Абсолютно стандартная страница из документации.

Ок, первый шаг сделан.

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

вооот. меня тоже это интересует!
...
Рейтинг: 0 / 0
10.10.2018, 18:43
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715731
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
love_bach,

HttpStatusCode.NotFound это 404
Вы сговорились?
...
Рейтинг: 0 / 0
10.10.2018, 18:58
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715732
love_bach
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
love_bach
Участник
Парамонlove_bach,

HttpStatusCode.NotFound это 404
Вы сговорились?

нет. это Хвост, собака его за ногу. Не так?
...
Рейтинг: 0 / 0
10.10.2018, 19:00
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715733
love_bach
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
love_bach
Участник
я всегда NoContent возвращал. но сейчас я в замешательстве
...
Рейтинг: 0 / 0
10.10.2018, 19:01
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715735
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
ПарамонТут могла быть ошибка, и тогда вменяемый сервис вернет 4xx.

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

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

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

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

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

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

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

Я не вижу никаких противоречий, смеешься над собой.
...
Рейтинг: 0 / 0
10.10.2018, 19:05
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715737
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
Парамонps
Как бы практика серьезных, мировых лидеров в этой области заслуживает внимания, в отличае от форумных Д’Артаньянов.

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

Твой ответ:

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

Понимаешь, как ты выглядишь? Не обуссудь.
...
Рейтинг: 0 / 0
10.10.2018, 19:08
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715742
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
handmadeFromRuя тебе уже объяснил что по последнему rcf http трактуют как протокол уровень приложения, так как это уровень приложения он должен показывать состояние, там четко написано что 400 это ошибки клиента и не важно какие.

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


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

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


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

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

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

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

моя аргументация пока не поколебима.
...
Рейтинг: 0 / 0
10.10.2018, 19:19
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715748
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
hVosttЯ до сих пор не увидел с какого боку, перепугу, по какой нахрен религии
сервис, возвращающий в 400 бизнесовые сообщения является вменяемым.

Ладно, будем как в школе, на пальцах.

Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
HTTP/1.1 400 Bad Request
Content-Type: application/json; charset=utf-8
Content-Length: 320

{
  "Message": "The request is invalid.",
  "ModelState": {
    "item": [
      "Required property 'Name' not found in JSON. Path '', line 1, position 14."
    ],
    "item.Name": [
      "The Name field is required."
    ],
    "item.Price": [
      "The field Price must be between 0 and 999." // внимание!
    ]
  }
}



Итак обсудим для на чала цену.

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

Ты вообще учавствовал в разработке коммерческих API, или только сам себе на страничку данные слал?
...
Рейтинг: 0 / 0
10.10.2018, 19:30
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715750
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
love_bach,

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

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

спрашивается, не противоречит ли это тому, что это ошибка протокола?
нет, так как здесь всё завязано на URL, и никакой логики дальше проверки наличия ресурса не выполняется.
также, ответ на URL может быть закеширован, на основе этого кода могут решаться проблемы перебора адресов и атак, это также отвечает безопасности.
...
Рейтинг: 0 / 0
10.10.2018, 19:30
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715753
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
love_bachПарамонТеперь экзамен.
Какой статус вернет сервис в случае, когда продукт не найден в базе данных?

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

404, это ошибка уровня протокола.
и да, протокол HTTP является прикладным, а не уровня приложения, но это уже для чукчей
...
Рейтинг: 0 / 0
10.10.2018, 19:32
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715757
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
Парамон
Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
HTTP/1.1 400 Bad Request
Content-Type: application/json; charset=utf-8
Content-Length: 320

{
  "Message": "The request is invalid.",
  "ModelState": {
    "item": [
      "Required property 'Name' not found in JSON. Path '', line 1, position 14."
    ],
    "item.Name": [
      "The Name field is required."
    ],
    "item.Price": [
      "The field Price must be between 0 and 999." // внимание!
    ]
  }
}



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

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

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


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

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

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

Поэтому я основываюсь не только на логике, RFC, но и на опыте взаимодействия.
Можешь конечно не верить, я не против.
...
Рейтинг: 0 / 0
10.10.2018, 19:40
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715760
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
hVosttВ ASP.NET ошибка 500 приводит в том числе по неотловленному эксепшену. т.е. это явная ошибка программистов ПО. Вы это тестируете? Предсказываете все ошибки?
Если тестировение выявило ошибку 500, она должна быть исправленна в короткий срок, в отличае от той же 501, которая может ждать, а может вообще так и остатся.
Что здесь сложно понять?
...
Рейтинг: 0 / 0
10.10.2018, 19:46
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715762
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
hVosttВыделенное приводит к ошибке 400.

Про цену вообщето писал, или ты разделишь на два ответа, один 200, другой 400?

hVosttМожешь конечно не верить, я не против.
Ага.
...
Рейтинг: 0 / 0
10.10.2018, 19:49
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715768
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
ПарамонЕсли тестировение выявило ошибку 500, она должна быть исправленна в короткий срок, в отличае от той же 501, которая может ждать, а может вообще так и остатся.
Что здесь сложно понять?

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

Обычно такая ошибка используется в процессе разработки и не доходит до прода. И это удобно, так как не нужно знать подробностей реализации и формат сообщений, чтобы понять, что такой URL обрабатывается, но не реализован.
...
Рейтинг: 0 / 0
10.10.2018, 19:58
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715769
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
ПарамонhVosttВыделенное приводит к ошибке 400.

Про цену вообщето писал, или ты разделишь на два ответа, один 200, другой 400?

Нет, отсутствие необходимого поля нивелирует остальной ответ. Он просто нафиг там не упёрся. Если тебе суп с мухой или волосами принесут, ты же будешь проверять его на вкус?
...
Рейтинг: 0 / 0
10.10.2018, 19:59
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715772
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
hVosttТы не прав. 501 ошибку возвращать нормально. Но если приложение клиента делает обращения к таким методам, т.е. ошибка регистрируется, значит она должна быть исправлена в короткий срок на стороне приложения.

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

Чувствуется отсутствие опыта. Сервис может обрастать функционалом постепенно, а не выкатываться весь через 20 лет. Но клиент не изучивший доку, может таки прислать запрос на нереализованный на данном этапе функционал, и это вполне нормально выдать ему 501 в продакшене.

hVosttНет, отсутствие необходимого поля нивелирует остальной ответ.
Значит, в таком случае, ответ с кодом 400 будет содержать и ошибки протокола и логики.
Что и нужно было доказать.
Больше вопросов нет ))
...
Рейтинг: 0 / 0
10.10.2018, 20:10
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715776
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
ПарамонЧувствуется отсутствие опыта. Сервис может обрастать функционалом постепенно, а не выкатываться весь через 20 лет. Но клиент не изучивший доку, может таки прислать запрос на нереализованный на данном этапе функционал, и это вполне нормально выдать ему 501 в продакшене.

Сорян, опыт говнокодинга мне не нужен. Нормально выдать 501 в продакшен, но не нормально в продакшене такое получать. Пользователю что показывать?

Чувствуется опыт херака-херака ))


ПарамонЗначит, в таком случае, ответ с кодом 400 будет содержать и ошибки протокола и логики.
Что и нужно было доказать.
Больше вопросов нет ))

Задачи убедить или научить тебя у меня нет.
Хочешь, суй свои ответы в какие хочешь коды, это законом не запрещено.
Но обоснований у тебя нет, а у меня есть.
...
Рейтинг: 0 / 0
10.10.2018, 20:22
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715780
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
hVosttНормально выдать 501 в продакшен, но не нормально в продакшене такое получать. Пользователю что показывать?
Какой пользователь? API поставляется разработчикам, которые в свою очередь не должны предоставлять такой функционал конечному юзеру, но вполне могут столкнится с этим в процессе разработки.
Как с луны свалился.
hVosttЗадачи убедить или научить тебя у меня нет.
Слив засчитан.
10 ошибок логики и одна протокола это 400.
15 ошибок логики это 200.
...
Рейтинг: 0 / 0
10.10.2018, 20:33
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715793
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
Парамон,

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

Ничего страшного, с опытом придет.
...
Рейтинг: 0 / 0
10.10.2018, 21:06
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715803
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
hVostt,

У тебя ошибки бизнеса приходят иногда со статусом 200, иногда 400.
Тут уже не нужны никакие аргументы и коментарии.
Это просто каша
...
Рейтинг: 0 / 0
10.10.2018, 21:32
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715804
Фотография Где-то в степи
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Где-то в степи
Участник
Забираем разнародные данные из api партнера , у всех ответов стандартная обертка где присутствует поле, где по русский простым
языком написан резульат запроса, ( или успех, или какая проблема ) гугл так практикует с мапами, вполне удобно и практично.
...
Рейтинг: 0 / 0
10.10.2018, 21:33
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715808
handmadeFromRu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
handmadeFromRu
Участник
AddxhandmadeFromRu,

Я понял, по RFC.
Но все же, у меня два разных случая.
Хотелось бы знать ответ для одного и для другого.
хм я же ответил. повторю что 404 по текущему стандарту для рест

на основе вот такой фразы:

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;

которая говорит что не только когда урл не найдет, но и запрашиваемый ресурс. протокол стал гибче.
...
Рейтинг: 0 / 0
10.10.2018, 21:37
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715813
handmadeFromRu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
handmadeFromRu
Участник
hVostt
чел вот мне честно не интересно с тобой дальше продолжать мусолить тему. вот будешь рулит мной - будешь качать права.
твои доводы меня не убедили. по rfc7231 написано что 400 можно юзать для client error, а это может быть что угодно.
я могу ответить на любой твой вопрос ко мне, но толку не будет все равно, это вызовет очередной виток переписки.

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

я считаю что тему можно закрывать она не приведет ни к чему.
...
Рейтинг: 0 / 0
10.10.2018, 21:50
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715836
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ViPRos
Участник
какой код тут должен быть?


Syncfusion is a United States company and is subject to US export laws. Consequently, due to your location, we may not allow access to any material on our site.
If you believe that this is inaccurate, please contact sales@syncfusion.com Thank you.
We are unable to service your request.
...
Рейтинг: 0 / 0
10.10.2018, 22:52
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715840
handmadeFromRu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
handmadeFromRu
Участник
Где-то в степиЗабираем разнародные данные из api партнера , у всех ответов стандартная обертка где присутствует поле, где по русский простым
языком написан резульат запроса, ( или успех, или какая проблема ) гугл так практикует с мапами, вполне удобно и практично.
гугл сделало это для поддержки совместимости больше взвесив все за и против да и закрытое у них апи мапы..весь api карт - это iframe или javascript библиотека, они могут тут все что угодно вытворят.
потому что если ты возьмешь по свежее вещи от того же гугла https://developers.google.com/drive/api/v3/handle-errors
...
Рейтинг: 0 / 0
10.10.2018, 22:58
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715861
Дмитрий Мух
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дмитрий Мух
Участник
ViPRosкакой код тут должен быть?


Syncfusion is a United States company and is subject to US export laws. Consequently, due to your location, we may not allow access to any material on our site.
If you believe that this is inaccurate, please contact sales@syncfusion.com Thank you.
We are unable to service your request.
Прямым текстом написано, что Forbidden
...
Рейтинг: 0 / 0
11.10.2018, 00:14
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715881
stenford
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
stenford
Участник
handmadeFromRuпричем тут нежные? мне не нравиться общаться с человеком который считает нормальным через слово говорить оппоненту что он дурак. хвост я за время дисскусии с тобой ни разу не посмел тебя назвать дураком или еще что то, так почему ты позволяешь себе это?
твоя же аргументация ..лалалалал дебилы..лалалалла да вы упоротные...лалалалала головой не думают (текст приблизительный но суть отражает)
у мальчика сильный комплекс неполноценности, что в совокупности с мизерным опытом участия в коммерческих проектах приводит вот к таким результатам. Обычно подобных д'артаньянов быстро выкидывают из команды, либо в крайнем случае пересаживают кодить низкоуровневые интерфейсы что-б не мешался под ногами
...
Рейтинг: 0 / 0
11.10.2018, 05:26
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39715934
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
stenfordОбычно подобных д'артаньянов быстро выкидывают из команды, либо в крайнем случае пересаживают кодить низкоуровневые интерфейсы что-б не мешался под ногами
По себе людей не судят
...
Рейтинг: 0 / 0
11.10.2018, 10:01
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716022
Addx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Addx
Участник
skyANA...


Раз уж Вы все равно читаете дискуссию ;)
может и свое мнение выразите? )
Без перехода на "все дураки" разумеется, как некоторые тут делают.
...
Рейтинг: 0 / 0
11.10.2018, 11:56
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716045
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
AddxskyANAМдааааа, развели срач...

Что полезного-то в итоге? То, что пора звать модератора?

Модератора-то за что? :))
это дружба)). Т.е. смешивание личного и служебного).
...
Рейтинг: 0 / 0
11.10.2018, 12:22
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716050
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
Addx,
по поводу ответов в топике, то мне ближе точка зрения ваша и hVostt в топике)).
Хотя я не максималист, и в некоторых проектах допустимо использование методов оппонентов.
Главное разделять статусы протокола от статусов и логике REST.
Не смешивать.
...
Рейтинг: 0 / 0
11.10.2018, 12:25
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716057
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
приводимый пример
Код: c#
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
HTTP/1.1 400 Bad Request
Content-Type: application/json; charset=utf-8
Content-Length: 320

{
  "Message": "The request is invalid.",
  "ModelState": {
    "item": [
      "Required property 'Name' not found in JSON. Path '', line 1, position 14."
    ],
    "item.Name": [
      "The Name field is required."
    ],
    "item.Price": [
      "The field Price must be between 0 and 999."
    ]
  }
}


странный для _простого API_
Какого фига я должен на бэке собирать все ошибки и выдавать на клиента?
Обычно я по первой ошибке Критической отправляю один ответ о невыполнении запроса.
Выше уже говорил - образец это API субд.
- возврат только
ORA-12345 и всё.
Как вариант:
21695072

или даже)

HTTP/1.1 200 Bad Request
Content-Type: application/json; charset=utf-8
Content-Length: 4
1001

или

HTTP/1.1 200
Content-Type: application/json; charset=utf-8
Content-Length: 320
{
Result: 'OK',
Warning: 'ssssssssssssss'
}
...
Рейтинг: 0 / 0
11.10.2018, 12:32
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716061
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
Ну и по поводу статуса 400, то я бы не мешал статусы толстого клиента и ошибки 400.
Т.е. применял бы 400 для ошибки: "Размер файла закачки на сервер более 1Гбт".
Или "Клиент прислал две куки аутентификации. Запрос не выполнен".
И т.д.
Т.е. ошибки транспорта.
Тогда на них можно реагировать без всяких программистов. Поставив админом прокси и задерживать такие запросы (отфутболивать) раньше АппСервера
...
Рейтинг: 0 / 0
11.10.2018, 12:37
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716150
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
handmadeFromRuчел вот мне честно не интересно с тобой дальше продолжать мусолить тему. вот будешь рулит мной - будешь качать права.
твои доводы меня не убедили. по rfc7231 написано что 400 можно юзать для client error, а это может быть что угодно.
я могу ответить на любой твой вопрос ко мне, но толку не будет все равно, это вызовет очередной виток переписки.

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

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

Блин, ну и зачем ты начинаешь? Нет не написано, что 400 можно юзать для бизнес-логики, не написано этого.
Ты можешь что угодно использовать, как угодно и где угодно.

Но врать не нужно.
...
Рейтинг: 0 / 0
11.10.2018, 14:07
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716152
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
stenfordу мальчика сильный комплекс неполноценности, что в совокупности с мизерным опытом участия в коммерческих проектах приводит вот к таким результатам. Обычно подобных д'артаньянов быстро выкидывают из команды, либо в крайнем случае пересаживают кодить низкоуровневые интерфейсы что-б не мешался под ногами

словесный понос какой-то.
я говорю по существу, и даю свою характеристику СЛОВАМ, а не ЛЮДЯМ.

неспособность абстрагироваться и не принимать на личный счёт, это возрастная проблема, проходит с возрастом.

у тебя она видимо, до сих пор не прошла.
...
Рейтинг: 0 / 0
11.10.2018, 14:10
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716154
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
Petro123Ну и по поводу статуса 400, то я бы не мешал статусы толстого клиента и ошибки 400.
Т.е. применял бы 400 для ошибки: "Размер файла закачки на сервер более 1Гбт".
Или "Клиент прислал две куки аутентификации. Запрос не выполнен".
И т.д.
Т.е. ошибки транспорта.
Тогда на них можно реагировать без всяких программистов. Поставив админом прокси и задерживать такие запросы (отфутболивать) раньше АппСервера

Всё верно.

Нужно знать для чего ты что-то делаешь.
А не пытаться сортировать по "цвету" учитывая своё личное цветовосприятие.
...
Рейтинг: 0 / 0
11.10.2018, 14:12
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716159
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
handmadeFromRuГде-то в степиЗабираем разнародные данные из api партнера , у всех ответов стандартная обертка где присутствует поле, где по русский простым
языком написан резульат запроса, ( или успех, или какая проблема ) гугл так практикует с мапами, вполне удобно и практично.
гугл сделало это для поддержки совместимости больше взвесив все за и против да и закрытое у них апи мапы..весь api карт - это iframe или javascript библиотека, они могут тут все что угодно вытворят.
потому что если ты возьмешь по свежее вещи от того же гугла https://developers.google.com/drive/api/v3/handle-errors
Удивительно, там нет статуса 200 с ошибкой. Дилетанты кругом
...
Рейтинг: 0 / 0
11.10.2018, 14:20
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716166
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
Petro123HTTP/1.1 200 Bad Reques
Еще один ))
...
Рейтинг: 0 / 0
11.10.2018, 14:42
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716182
handmadeFromRu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
handmadeFromRu
Участник
hVostt,

как ты относишься к книге RESTful Web Services Cookbook? автор так себе или нормас спец? ну там всего то архитектор ебей так то.
...
Рейтинг: 0 / 0
11.10.2018, 15:13
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716189
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
handmadeFromRuhVostt,

как ты относишься к книге RESTful Web Services Cookbook? автор так себе или нормас спец? ну там всего то архитектор ебей так то.

Скажет, что прикрываешься авторитетами.
Стратегию ещё не выучил? )
...
Рейтинг: 0 / 0
11.10.2018, 15:20
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716213
Addx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Addx
Участник
handmadeFromRu,

Если бы автор был на форуме, я бы с удовольствием с ним подискутировал.
Общаться и дискутировать со ссылками несколько затруднительно.
...
Рейтинг: 0 / 0
11.10.2018, 15:56
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716216
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
ПарамонhandmadeFromRuгугл сделало это для поддержки совместимости больше взвесив все за и против да и закрытое у них апи мапы..весь api карт - это iframe или javascript библиотека, они могут тут все что угодно вытворят.
потому что если ты возьмешь по свежее вещи от того же гугла https://developers.google.com/drive/api/v3/handle-errors
Удивительно, там нет статуса 200 с ошибкой. Дилетанты кругом

Удивительно, но код ошибки мы видим ВНУТРИ JSON

Код: javascript
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
{
  "error": {
    "errors": [
      {
        "domain": "global",
        "reason": "badRequest",
        "message": "Bad Request"
      }
    ],
    "code": 400,
    "message": "Bad Request"
  }
}



Вы бы хоть сами смотрели, прежде чем постить. Ребят. Потом вы ОБИЖАЕТЕСЬ, когда я говорю, что вы несёте ЧУШЬ.
...
Рейтинг: 0 / 0
11.10.2018, 16:00
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716218
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
Скажите пожалуйста, ещё раз.

Куда вы бизнесовые коды запихаете? Например, все коды инцидентов пронумерованы, их много. Тысячи. Куда вы их сложите?

И опять таки. Вопрос до сих пор открытый.

Для чего вам код ошибки HTTP?
Какую цель вы преследуете?
Какую задачу таким образом решаете?

Обычный ответ с 200, в котором вы что угодно можете прописать, какие угодно коды, какие угодно форматы мессаджей, какие угодно уровни критичности, контекст, условия и т.д. и т.п.

Что вам код 400 даёт?
...
Рейтинг: 0 / 0
11.10.2018, 16:03
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716222
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
handmadeFromRuhVostt,

как ты относишься к книге RESTful Web Services Cookbook? автор так себе или нормас спец? ну там всего то архитектор ебей так то.

Отлично отношусь. Хорошо.
...
Рейтинг: 0 / 0
11.10.2018, 16:06
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716224
handmadeFromRu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
handmadeFromRu
Участник
hVosttПарамонпропущено...

Удивительно, там нет статуса 200 с ошибкой. Дилетанты кругом

Удивительно, но код ошибки мы видим ВНУТРИ JSON

Код: javascript
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
{
  "error": {
    "errors": [
      {
        "domain": "global",
        "reason": "badRequest",
        "message": "Bad Request"
      }
    ],
    "code": 400,
    "message": "Bad Request"
  }
}



Вы бы хоть сами смотрели, прежде чем постить. Ребят. Потом вы ОБИЖАЕТЕСЬ, когда я говорю, что вы несёте ЧУШЬ.

ну так проверь еще раз там помимо кода еще и http статус
...
Рейтинг: 0 / 0
11.10.2018, 16:07
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716225
handmadeFromRu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
handmadeFromRu
Участник
hVostthandmadeFromRuhVostt,

как ты относишься к книге RESTful Web Services Cookbook? автор так себе или нормас спец? ну там всего то архитектор ебей так то.

Отлично отношусь. Хорошо.
тогда открой страницу 70
и там написано :
One common mistake that some web services make is to return a status code that reflects success (status codes from 200 to 206 and from 300 to 307) but include a message body that describes an error condition. Doing this prevents HTTP-aware software from detecting errors. For example, a cache will store it as successful response and serve it to subsequent clients even when clients may be able to make a successful request.
...
Рейтинг: 0 / 0
11.10.2018, 16:08
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716235
Addx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Addx
Участник
handmadeFromRu,

где тут сказано, что это относится к бизнес-логике?
Это классический пример - вырвать фразу из контекста, и использовать как доказательство.
Любимый прием журналистов.
...
Рейтинг: 0 / 0
11.10.2018, 16:16
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716240
handmadeFromRu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
handmadeFromRu
Участник
AddxhandmadeFromRu,

Если бы автор был на форуме, я бы с удовольствием с ним подискутировал.
Общаться и дискутировать со ссылками несколько затруднительно.
я тут солидарен)
...
Рейтинг: 0 / 0
11.10.2018, 16:25
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716246
handmadeFromRu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
handmadeFromRu
Участник
AddxhandmadeFromRu,

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

вы праве не считать это аргументом, если читали книгу, возможно мы пришли к разным выводам.
...
Рейтинг: 0 / 0
11.10.2018, 16:32
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716253
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
hVosttПарамонпропущено...

Удивительно, там нет статуса 200 с ошибкой. Дилетанты кругом

Удивительно, но код ошибки мы видим ВНУТРИ JSON

Код: javascript
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
{
  "error": {
    "errors": [
      {
        "domain": "global",
        "reason": "badRequest",
        "message": "Bad Request"
      }
    ],
    "code": 400,
    "message": "Bad Request"
  }
}




Вы бы хоть сами смотрели, прежде чем постить. Ребят. Потом вы ОБИЖАЕТЕСЬ, когда я говорю, что вы несёте ЧУШЬ.

Ну зачем так позорится? Показывать подтверждение моих слов, пытаясь изменить контекст.
Там это написано в первой строчке, и есть возможность тестировать сервис онлайн.

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

И да, обрати внимание, не поверишь, но там есть код 500, да-да в продакшене!

Вернись лучше к тактике в стиле - "не подписывай авторитетов" )
...
Рейтинг: 0 / 0
11.10.2018, 16:39
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716254
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
handmadeFromRu,
В сети есть как любители пихать в код 200, так и в код 400.
Из вендоров Гугл пихает в 200.
...
Рейтинг: 0 / 0
11.10.2018, 16:40
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716258
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
Addxгде тут сказано, что это относится к бизнес-логике?
Там вообще сказано, что не важно какие условия, но выдавать в теле сообщения ошибку и при этом успешный статус, есть тупость common mistake.

Дальше расписано почему.
...
Рейтинг: 0 / 0
11.10.2018, 16:44
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716260
Addx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Addx
Участник
Petro123,

Из фееричного у меня было, когда пихали в код 500 "потому что мы не понимаем почему от ваших запросов у нас падает сервер" ))
Открывашь JSON и смотришь, что там на самом деле происходит. ))
Т.е. там видно, прошел запрос или нет, а вот упал при этом сервер у них или нет, для бизнес-пользователей не так интересно. ))
...
Рейтинг: 0 / 0
11.10.2018, 16:47
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716267
handmadeFromRu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
handmadeFromRu
Участник
Petro123handmadeFromRu,
В сети есть как любители пихать в код 200, так и в код 400.
Из вендоров Гугл пихает в 200.
ну гугл я скинул ссылку и там статусы http. я б не сказал что они четко 200
...
Рейтинг: 0 / 0
11.10.2018, 16:53
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716268
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
Господа.
Статус rest или warning предупреждение по бизнесу не имеет отношение к HTTP.Error.
Пример - пришла пустая коллекция на клиента.
В модуле бизнеса не будет даже кода 200.
...
Рейтинг: 0 / 0
11.10.2018, 16:54
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716271
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
handmadeFromRuPetro123handmadeFromRu,
В сети есть как любители пихать в код 200, так и в код 400.
Из вендоров Гугл пихает в 200.
ну гугл я скинул ссылку и там статусы http. я б не сказал что они четко 200 Поищу ссылку. Вроде сервис геокодирования.
...
Рейтинг: 0 / 0
11.10.2018, 16:55
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716278
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
handmadeFromRu,
Тут глянь.
200?
https://developers.google.com/maps/documentation/geocoding/intro#StatusCodes
...
Рейтинг: 0 / 0
11.10.2018, 17:04
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716287
handmadeFromRu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
handmadeFromRu
Участник
Petro123handmadeFromRu,
Тут глянь.
200?
https://developers.google.com/maps/documentation/geocoding/intro#StatusCodes

да 200 там.
http://joxi.ru/823nnxlS98goom
а чуть ниже в скрине пример на их драйв

или вот такой пример твитера
https://developer.twitter.com/en/docs/basics/response-codes.html
...
Рейтинг: 0 / 0
11.10.2018, 17:11
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716289
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
Petro123Пример - пришла пустая коллекция на клиента.
Кто тебе сказал, что пустая коллекция это исключение?
Petro123В модуле бизнеса не будет даже кода 200
Будет.
...
Рейтинг: 0 / 0
11.10.2018, 17:13
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716297
Addx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Addx
Участник
handmadeFromRu...
или вот такой пример твитера
...


Два их кода возврата вызывают некоторые сомнения ;),
остальные абсолютно логичны. Сделал бы их так же :)
(ну примерно в таком стиле)
...
Рейтинг: 0 / 0
11.10.2018, 17:25
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716311
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
handmadeFromRuтогда открой страницу 70
и там написано :
One common mistake that some web services make is to return a status code that reflects success (status codes from 200 to 206 and from 300 to 307) but include a message body that describes an error condition. Doing this prevents HTTP-aware software from detecting errors. For example, a cache will store it as successful response and serve it to subsequent clients even when clients may be able to make a successful request.

Ну так и в чём противоречие? Ошибка прикладного уровня: отправили не то, что ожидалось = ошибка. Нормальная ситуация = success.

Обрати внимание на фразу "Doing this prevents HTTP-aware software from detecting errors ."

Давай рассмотрим форму поиска пользователя по фамилии. Результат возвращает коллекцию найденных работников. Что по-твоему приложение должно возвращать, если не нашлось ни одного работника? 400? 404? 500?

Некая форма ввода. Пользователи часто ошибаются при вводе, вводят невалидные данные. Это нормальная ситуация .

Обычная форма логина.

https://passport.yandex.ru/auth/welcome
https://accounts.google.com/signin/v2/sl/pwd?service=mail

Вводи что угодно, любые неправильные логины и пароли.
ЧТо увидишь в ответ?

200

Потому, что это НОРМАЛЬНАЯ ситуация. Это НЕ ошибка.

Вам так нравятся примеры "больших дядек".
Ну так вот, держите и распишитесь.

Вы напишите им, чё это вы против миллионного коммьюнити? Книжек не читали? Статей? Блогов!?
...
Рейтинг: 0 / 0
11.10.2018, 17:45
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716313
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
https://developer.twitter.com/en/docs/basics/response-codes.html

автор
400 Bad Request The request was invalid or cannot be otherwise served. An accompanying error message will explain further. Requests without authentication are considered invalid and will yield this response.



Такие ошибки говорят о проблемах. А нормальные бизнес-ситуация, негативные сценарии -- это не проблема для прикладного уровня протокола.

И моё удивление, а так же резкая оценка ваших умозаключений относятся к тому, что вы тупо отказываетесь понимать простую и очевидную разницу. Что я могу сказать? Сейчас уже только посочувствовать вашей проблеме.
...
Рейтинг: 0 / 0
11.10.2018, 17:50
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716315
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
Petro123В модуле бизнеса не будет даже кода 200.

А вот и нет, будет!! Ахахаххх...
...
Рейтинг: 0 / 0
11.10.2018, 17:50
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716325
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
hVostt
Ну так и в чём противоречие? Ошибка прикладного уровня: отправили не то, что ожидалось = ошибка. Нормальная ситуация = success.

Обрати внимание на фразу "Doing this prevents HTTP-aware software from detecting errors ."

Давай рассмотрим форму поиска пользователя по фамилии. Результат возвращает коллекцию найденных работников. Что по-твоему приложение должно возвращать, если не нашлось ни одного работника? 400? 404? 500?

Некая форма ввода. Пользователи часто ошибаются при вводе, вводят невалидные данные. Это нормальная ситуация .

Обычная форма логина.

https://passport.yandex.ru/auth/welcome
https://accounts.google.com/signin/v2/sl/pwd?service=mail

Вводи что угодно, любые неправильные логины и пароли.
ЧТо увидишь в ответ?

200

Потому, что это НОРМАЛЬНАЯ ситуация. Это НЕ ошибка.

Тебя не туда понесло.
Если пользователь ошибся, это однозначно не нормальная ситуация.

В случае разных поисковых параметров, пользователь не может ошибатся.
Пробовать найти: key=ко, key=133, key=коля, key=петя, key=asfafфва24234.
Это все нормально. Он пробует, ищет.
Если в место key будет keyyy, это ошибка 400.

Он может пробовать любые условия (кроме попыток взлома или завалить сервер и тд) и это нормально и валидно.

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

Почему? Потому, что сегодня он ничего не нашел по своему запросу, а завтра, кто его знает, может и найдет.

Пример:
Юзер шлет запрос сервису: Верни мне всех пользователей, которые в данный момент онлайн .
Допустим их нет.
Зачем просить его исправь запрос, ведь через минуту их может быть 15 и запрос не изменится.

На 400, мы хотим, что бы запрос изменися , простое правило.

Неправильная авторизация это 401 Unauthorized.

Снова тривиальные вещи расписываю.
...
Рейтинг: 0 / 0
11.10.2018, 18:36
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716329
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
Парамон На 400, мы хотим, что бы запрос изменися да.
Пример - урл написан большими буквами.
...
Рейтинг: 0 / 0
11.10.2018, 18:42
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716332
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
ПарамонЕсли в место key будет keyyy, это ошибка 400.начали с бизнес логики и цены пылесоса, а тут уже до 404 рукой подать).
...
Рейтинг: 0 / 0
11.10.2018, 18:50
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716334
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
Petro123ПарамонЕсли в место key будет keyyy, это ошибка 400.начали с бизнес логики и цены пылесоса, а тут уже до 404 рукой подать).
Любой логики, чем читаешь? 404 включительно.
...
Рейтинг: 0 / 0
11.10.2018, 18:57
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716336
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
Petro123Парамон На 400, мы хотим, что бы запрос изменися да.
Пример - урл написан большими буквами.
Про урл читай в категории 3xx.
...
Рейтинг: 0 / 0
11.10.2018, 19:00
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716339
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
ПарамонТебя не туда понесло.
Если пользователь ошибся, это однозначно не нормальная ситуация.

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

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



ПарамонТы ведь не скажешь, твой запрос не правильный, нужно исправить, в отличае от статуса 400, который явно подразумевает исправление запроса .

Предлагаешь пользователю исправить формат отправляемых данных? Или формат сообщения? Указать правильные заголовки HTTP запроса?

Валидация -- это отработка негативных сценариев, это не ошибка работы взаимодействия или приложения.




ПарамонПример:
Юзер шлет запрос сервису: Верни мне всех пользователей, которые в данный момент онлайн .
Допустим их нет.
Зачем просить его исправь запрос, ведь через минуту их может быть 15 и запрос не изменится.

На 400, мы хотим, что бы запрос изменися , простое правило.

Ну погоди. Ты осуществляешь перевод из своего счёта на другой и вписываешь 1000 рублей. Но оказывается на счету нет столько денег, по-твоему надо вернуть 400, якобы "плохой" запрос и его надо изменить?

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

Понимаешь, что логика у тебя пипец ущербная?


ПарамонСнова тривиальные вещи расписываю.

Ты очень жёстко фантазируешь и натягиваешь глаз на ж. Извращенец )
...
Рейтинг: 0 / 0
11.10.2018, 19:02
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716343
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
hVosttПредлагаешь пользователю исправить формат отправляемых данных? Или формат сообщения? Указать правильные заголовки HTTP запроса?
Исправить, то в чем было разногласие с логикой на стороне сервера, это мугут быть загаловки, тело запроса и тд.
hVosttНу погоди. Ты осуществляешь перевод из своего счёта на другой и вписываешь 1000 рублей. Но оказывается на счету нет столько денег, по-твоему надо вернуть 400, якобы "плохой" запрос и его надо изменить?
409.

13 страниц, а ничему не учишься.
...
Рейтинг: 0 / 0
11.10.2018, 19:18
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716344
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
hVosttНу погоди. Ты осуществляешь перевод из своего счёта на другой и вписываешь 1000 рублей. Но оказывается на счету нет столько денег, по-твоему надо вернуть 400, якобы "плохой" запрос и его надо изменить?

Не, ну ты конечно вернешь - код 200, все ОК, только денег нет, но вы там держитесь, хорошего настроения.
...
Рейтинг: 0 / 0
11.10.2018, 19:24
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716345
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
Парамон409.

13 страниц, а ничему не учишься.

Парамон, теперь я окончательно убедился, что ты упорот, либо ник настоящего Парамона оккупировал какой-то недалёкое школоло, ну либо ппц.

В общем, мне надоело. Хорошо, в моей практике в работе в крупных компаниях с большими и малыми командами такой идиотии не встречается.
...
Рейтинг: 0 / 0
11.10.2018, 19:26
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716347
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
ПарамонНе, ну ты конечно вернешь - код 200, все ОК, только денег нет, но вы там держитесь, хорошего настроения.

Я тебе две ссылки привёл


https://passport.yandex.ru/auth/welcome
https://accounts.google.com/signin/v2/sl/pwd?service=mail

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

И у них всё хорошо. Возвращается 200 на неправильный ввод пользователя.
Поэтому иди лесом
...
Рейтинг: 0 / 0
11.10.2018, 19:27
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716351
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
hVosttПарамон409.

13 страниц, а ничему не учишься.

Парамон, теперь я окончательно убедился, что ты упорот, либо ник настоящего Парамона оккупировал какой-то недалёкое школоло, ну либо ппц.

В общем, мне надоело. Хорошо, в моей практике в работе в крупных компаниях с большими и малыми командами такой идиотии не встречается.

А сам про личности ныл, не так давно. Снова бомбит, когда над тобой посмеялись в очередной раз?
И да, в крупных компаниях полно говнокода, говнокодеров и легаси.

hVosttэто очень крупные и уважаемые компании, гугл по-авторитетней амазона будет.
Авторитетами прикрылся? Чем авторитет одного относительно другого сравнивал? )
Тебе API гугля показывали, там с кодами все логично и правильно.
Про ситуацию с поиском то же подробо рассказали, но все туго.

Хотя, после того как ты заявил, что 402 payment required, это не бизнес логика, я уже ничему не удевляюсь.
...
Рейтинг: 0 / 0
11.10.2018, 19:43
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716353
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
Парамон,

Как прокоментируешь 200 на неправильный ввод пользователя гугля и Яндекса?
...
Рейтинг: 0 / 0
11.10.2018, 19:54
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716366
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
hVosttПарамон,

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

Ты разницу между комерческим restfull api, который поставляют разработчикам, и внутренними продуктами улавливаешь? Вижу, что нет.

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

Коду 100 лет, нет смысла его трогать, это ни кому не поставляют и документацию на него не пишут.

Сделай запросы к API гугля, и ты там увидишь 401 своими глазами, обещаю.

рука, лицо.
...
Рейтинг: 0 / 0
11.10.2018, 20:28
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716384
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
Парамон,

Ну ясно. Не можешь внятно объяснить.

Окей.

Смотрим сюды: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/400

The HyperText Transfer Protocol (HTTP) 400 Bad Request response status code indicates that the server could not understand the request due to invalid syntax .

The client should not repeat this request without modification .


Ну лан. Это фу какая-то мозила, это ж тебе не Амазон!

Идём дальше.

https://developers.facebook.com/docs/graph-api/using-graph-api/error-handling/

Оу. Все ошибки логики, вообще все возвращаются через 200 OK.
А коды ошибок указываются внутри.
Обрати внимание, сколько их там.

При чём ошибки протокола, кривые запросы таки прилетают в виде 400, и т.п., как я и говорил.

Пффф.. Кто вообще такой этот фейсбук?? Фигня какая-то.

Ну чё там у гугл? Рестфул подход, да?

https://developers.google.com/maps/documentation/geocoding/intro#StatusCodes

Логически неправильные запросы, возвращают 200, статус операции передаётся в поле "status"

Это всё уже плюсом к моим реальным аргументам, а не какому-то бульканью Парамона ))
...
Рейтинг: 0 / 0
11.10.2018, 21:37
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716391
handmadeFromRu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
handmadeFromRu
Участник
hVostt,

рест апи мозилы в студию
для фейсбука http://joxi.ru/p27669NSKNpkqm только не говори что когда у меня нет доступа это не ошибка логики по доступу

форма яндекса что ты указал.ты там где увидел рест? там обычная форма с постом.
форма гугла там 200 но ты видел что там рест апи? + я кидал пример по драйву там статус коды но ты это игнорируешь. тебе скинуть может что гугл отвечает на форму гугла http://joxi.ru/gmv66vySq1NVxm мега полезный пример

> Doing this prevents HTTP-aware software from detecting errors
начало что ты удалили где написано что оборачивать в 200 ошибку не есть хорошо, и твоя кописпаста говорит почему не хорошо

начали закидывать ссылками крутых контор вот тока почему ты не посмотрел ссылки что я скинул.
...
Рейтинг: 0 / 0
11.10.2018, 22:07
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716392
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
hVostt,

Можно я напомню, что мы тут говорим в контексте RESTFULL API и стандартов.
Твои примеры, не рест подход, и очень древние разработки, которые начинались в эпоху динозавров. И ты походу там и остался. Эдакий старый олдфаг, для которого кроме post, get и код 200, ничего не существует.

Смотри на новые, нормальные рест сервисы. Ссылок тебе накидали.
...
Рейтинг: 0 / 0
11.10.2018, 22:08
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716395
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
И да, по ссылкам не ходил. Возможно хвост как обычно читал по диагонали, а на деле не проверял и там все норм со статусами.
...
Рейтинг: 0 / 0
11.10.2018, 22:13
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716399
handmadeFromRu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
handmadeFromRu
Участник
hVosttСмотрим сюды: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/400

The HyperText Transfer Protocol (HTTP) 400 Bad Request response status code indicates that the server could not understand the request due to invalid syntax .

The client should not repeat this request without modification .


вопрос на засыпку мозила нынче стандарт или rfc7231?
...
Рейтинг: 0 / 0
11.10.2018, 22:18
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716400
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
hVostt,


hVosttСмотрим сюды: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/400

А теперь смотрим нормальный свежий подход

google авторитет хвоста400 Bad Request Bad Request/Invalid Arguments ( merchant, service, slot not found, trying to book an invalid slot, cancelling a booking that never existed ).
...
Рейтинг: 0 / 0
11.10.2018, 22:29
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716408
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
Парамон,
А что мы получаем смешивая 400 статус и 1500 кодов ошибок ошибочных запросов сервер <--> клиенты?
Смешивать с 200 не страшно. Это просто код рукопожатия, наличия канала.
А вот у 400 есть реальные юз кейсы.
Если в бэке давно не мешают слой БЛ и транспорт (DAL), то в клиенте мешать какой профит?
hVostt тоже выше про это тебя спрашивал.
...
Рейтинг: 0 / 0
11.10.2018, 22:57
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716412
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
handmadeFromRuрест апи мозилы в студию
для фейсбука http://joxi.ru/p27669NSKNpkqm только не говори что когда у меня нет доступа это не ошибка логики по доступу

Нет, авторизация это прикладной уровень. Почему 400, а не 403 -- хз.

handmadeFromRuформа яндекса что ты указал.ты там где увидел рест? там обычная форма с постом.

Я рад, что хоть ты соизволил проверить. Про формы с постом давно уже хотел сказать, решил на этом примере.

handmadeFromRuформа гугла там 200 но ты видел что там рест апи? + я кидал пример по драйву там статус коды но ты это игнорируешь. тебе скинуть может что гугл отвечает на форму гугла http://joxi.ru/gmv66vySq1NVxm мега полезный пример

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

Суть валидации: это непрерывный нормальный процесс. Люди постоянно ошибаются, и нахрена это видеть в логах ошибок? Это на какой планете вообще можно считать нормальным?

Какого ты привёл пример, который мало того, что не противоречит моим аргументам и утверждениям, так ещё вообще не относится к теме.


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

Я это сделал только ПОСЛЕ своих конкретных аргументов. Да и просто уже ради фана, вижу, что не пробиваемые, не желаете отвечать на вопросы (зачем вам нужны коды ошибок? для чего вы их используете? что это вам даёт при валидации, вместо 200? какой профит?...) только тычете "посмотри как у них". Ну посмотрел, и в ответ могу привести не меньше примеров от тех же дядей, на которых вы молитесь.
...
Рейтинг: 0 / 0
11.10.2018, 23:25
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716413
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
ПарамонМожно я напомню, что мы тут говорим в контексте RESTFULL API и стандартов.

REST это не протокол и не стандарт. Это просто архитектурный стиль, в котором нет никаких чётких предписаний. И он НЕ ДОЛЖЕН противоречить стандартам HTTP.


ПарамонТвои примеры, не рест подход, и очень древние разработки, которые начинались в эпоху динозавров. И ты походу там и остался. Эдакий старый олдфаг, для которого кроме post, get и код 200, ничего не существует.

Ни о чём.


ПарамонСмотри на новые, нормальные рест сервисы. Ссылок тебе накидали.

Видимо вы и можете, что только "накидать". Я тоже могу. Но я в отличие от вас аргументировал свою позицию и задал вопросы, на которые вы только буль-буль-буль.. Ничего не ответили.

В чём проблема-то?
...
Рейтинг: 0 / 0
11.10.2018, 23:28
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716414
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
handmadeFromRuhVosttСмотрим сюды: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/400

пропущено...


вопрос на засыпку мозила нынче стандарт или rfc7231?

Перейди по ссылке и найди ссылку на RFC, на чём основывается документация.

И найди в RFC что-то там про ошибочные/негативные ситуации логики приложения. Я не нашёл. А вы выдумываетет.
...
Рейтинг: 0 / 0
11.10.2018, 23:29
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716416
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
Парамон А теперь смотрим нормальный свежий подход

Ты какой-то модник. Главная чтобы було свежое, да?
...
Рейтинг: 0 / 0
11.10.2018, 23:30
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716418
handmadeFromRu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
handmadeFromRu
Участник
hVostt,

я ответил давно тебе и про коды, что они дают, но ты мне написал на это "дурачек" потому что ты так не считаешь, ахеренная аргументация)
я тебе дажe книжку скинул, но снова свое гнет. ладно все я пас. ничего не берет тебя.
...
Рейтинг: 0 / 0
11.10.2018, 23:34
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716419
ViPRos
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ViPRos
Участник
hVosttПарамон А теперь смотрим нормальный свежий подход

Ты какой-то модник. Главная чтобы було свежое, да?
олдфаг, блин :):):)
...
Рейтинг: 0 / 0
11.10.2018, 23:34
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716420
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
handmadeFromRuя ответил давно тебе и про коды, что они дают, но ты мне написал на это "дурачек" потому что ты так не считаешь, ахеренная аргументация)
я тебе дажe книжку скинул, но снова свое гнет. ладно все я пас. ничего не берет тебя.

Вообще-то ты всё свёл к тому, что пофигу чё там кто использует, это не принципиально.

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

И вообще ты сказал "http - это не просто транспортный протокол. это протокол уровня приложения.", т.е. коды ошибок HTTP проходят по бизнес-логике и все его тонкости в ней отображены. Я в это не поверил, значит ты перепутал понятия "прикладной уровень" и "уровень приложения".
...
Рейтинг: 0 / 0
11.10.2018, 23:39
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716421
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
handmadeFromRuhVostt,

я ответил давно тебе и про коды, что они дают, но ты мне написал на это "дурачек" потому что ты так не считаешь, ахеренная аргументация)
я тебе дажe книжку скинул, но снова свое гнет. ладно все я пас. ничего не берет тебя.не зацикливайся на прошлом.
"Все неглупые люди имеют очень скверный характер" (с)))))
Аргументы нужны здесь и сейчас.
...
Рейтинг: 0 / 0
11.10.2018, 23:48
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716422
handmadeFromRu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
handmadeFromRu
Участник
hVosttВообще-то ты всё свёл к тому, что пофигу чё там кто использует, это не принципиально.

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

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

я тебе привел свои аргумент, ты их обосрал и говоришь что не было аргументов

hVosttИ вообще ты сказал "http - это не просто транспортный протокол. это протокол уровня приложения.", т.е. коды ошибок HTTP проходят по бизнес-логике и все его тонкости в ней отображены. Я в это не поверил, значит ты перепутал понятия "прикладной уровень" и "уровень приложения".
это не я сказал, так говорил rfc. прям в начале текста.
хвост я не писал что HTTP проходит по бл. в бл возникает ошибка и она выкидывается. контролер решает каким кодом ответить. http отражает состояние запроса.

перестань мои слова выставлять в другом свете.
...
Рейтинг: 0 / 0
11.10.2018, 23:50
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716423
handmadeFromRu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
handmadeFromRu
Участник
Petro123handmadeFromRuhVostt,

я ответил давно тебе и про коды, что они дают, но ты мне написал на это "дурачек" потому что ты так не считаешь, ахеренная аргументация)
я тебе дажe книжку скинул, но снова свое гнет. ладно все я пас. ничего не берет тебя.не зацикливайся на прошлом.
"Все неглупые люди имеют очень скверный характер" (с)))))
Аргументы нужны здесь и сейчас.
а ты хорош)
...
Рейтинг: 0 / 0
11.10.2018, 23:50
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716432
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
handmadeFromRuhVosttВообще-то ты всё свёл к тому, что пофигу чё там кто использует, это не принципиально.

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

Это не продуктивный вывод. Речь шла не о том, кто там что используем, ходит ли в трусах по офису или ещё какую фигню вытворяет.

handmadeFromRuя тебе привел свои аргумент, ты их обосрал и говоришь что не было аргументов

Ты не приводил аргументов, ты критиковал мои, и при этом так и не ответил на простые вопросы.
И вот это странно )

handmadeFromRuэто не я сказал, так говорил rfc. прям в начале текста.
хвост я не писал что HTTP проходит по бл. в бл возникает ошибка и она выкидывается. контролер решает каким кодом ответить. http отражает состояние запроса.

Ну это же неправда. RFC ничего подобного не утверждает. Bad Request говорит о том, что запрос составлен корректно, об это говорится. С точки зрения бизнес-логики нет никакого "запроса". Это прикладной уровень взаимодействия.

Хорошо спроектированная архитектура изолирует бизнес-логику от протокола. Т.е. ты можешь её использовать напрямую, где нет никаких кодов.

Давай посмотрим на изначальный вопрос ТС?

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

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

Засунуть такие ситуации в Bad Request -- это тупо смешать мухи с котлетами.
Какой от этого вред -- очевидно. Но ты не хочешь его признавать.

Ну и хер с ним. Скажи, какой от этого профит? Для тебя? Нахрена тебе это надо? Чем тебе 200 для валидации не угодило?
...
Рейтинг: 0 / 0
12.10.2018, 01:33
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716442
Calabonga
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Calabonga
Гость
skyANA,


Много в чём. Например, на UI предопределенные обработчики созданые для OperationResult. На OperationResult куча extensions написано, под разные платформы, всё универсально потому что однотипно.
...
Рейтинг: 0 / 0
12.10.2018, 04:41
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716445
Calabonga
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Calabonga
Гость
hVosttCalabongaТяжело судить, что и почему вы там выпиливали, но могу со всей ответственностью заявить, что никогда не было проблем! Только профит! И на UI и на Backend.

Серьёзно? Не верю. Все фронтендщики с опытом и знаниями как один скажут, что 200 ОК на все случаи жизни это полнейший шит. Уж извините.

Админы скажут, вы ??*№Ц; издеваетесь?.. Как это адекватно мониторить ?

И т.д.


Зачем пониторить ошибки, которые не имеют отношения к бизнес логики? Мне кажется, что у вас, коллега, какая мания сложилась - всё "мониторить"... наверное это возрастное.
...
Рейтинг: 0 / 0
12.10.2018, 04:51
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716447
Calabonga
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Calabonga
Гость
handmadeFromRuCalabonga,
ну ты сам говорил что ошибки возвращаешь обернутые в 200. ты уже определись если пишешь что и бедреквест также шлешь.
потому что это противоречит тому что ты говорил в начале и также в твоей ссылке написано:

Сервер должен всегда возвращать один код ответа как результат обработки запроса. Это код 200. А всю дополнительную информацию требуется передавать в теле ответа.
Возможно я неправильно выразился, хотя я и писал где-то, что 500 ошибку сервер невозможно завернуть. Я имел в виду, что заворачиваются ошибки бизнес логики. Да и вообще, ошибка ошибке - рознь. Поэтому однозначно сказать, что "всё" - не совсем правильно. Всё хорошо с умом и в меру.
...
Рейтинг: 0 / 0
12.10.2018, 04:54
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716448
Calabonga
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Calabonga
Гость
hVosttCalabongaВидимо, у меня в моей статье не получилось донести до достопачтенной публики причину, почему я сделал OperationResult

OperationResult это отличное решение, позволяющее решать задачи на топ уровне в функциональном стиле.
но не стоит его переносить на уровень HTTP, как бы противоречие только здесь
Еще раз повторюсь, что я не оборачиваю ошибки HTTP протокола, напимер такие, как 500, потому что это невозможно да и смысла не имеет. Оборачиваются только ошибки БИЗНЕС-логики. Да и то, ошибка ошибке - рознь, всё хорошо в меру и с умом. :)
...
Рейтинг: 0 / 0
12.10.2018, 04:56
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716450
Calabonga
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Calabonga
Гость
hVostt
Давай на примитивном языке?

Я тебе говорю, ДАЙ МНЕ ЯБЛОК.
Ты отвечаешь У МЕНЯ НЕТ ЯБЛОК (200, так как ты меня понял, но яблок у тебя нет).
Когда я тебе говорю, ВЫПАК№ЦКаЫа32, ты говоришь Я ТЕБЯ НЕ ПОНИМАЮ.

Реал, мне уже страшно становится.
Вы что серьёзно вот этот вот, гоните, не знаете и не понимаете HTTP?

Мрааааак.

Вот тут-то как раз и включается OperationResult, когда яблок нет, а ответ 200. а когда "ВЫПАК№ЦКаЫа32" - то тут никакой wrapper не нужен потому что бессмысленно wrap делать для всякой хрени!
...
Рейтинг: 0 / 0
12.10.2018, 05:05
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716451
Calabonga
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Calabonga
Гость
ПарамонhVosttНу-ну. Я то на RFC опираюсь, а ты на какого-то Васю из стековерфлоу
На стековерфлоу опираются миллионы, больше половины твоих отсылов тут на этот ресурс, но вдруг там стало все плохо. Не хорошо в колодец то плевать )
Я даже перевел 21698262 , но увы, бисером метать устал (
стековерфлоу - полезный ресурс, но RFC - первична!
...
Рейтинг: 0 / 0
12.10.2018, 05:06
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716452
Calabonga
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Calabonga
Гость
hVosttПарамонВ двух словах. Если клиент ошибся с бизнес логикой, то сервис хвоста вернёт статус 200 и сообщение с ошибкой. Все.

В двух словах: HTTP, который используется для общения приложений клиента и сервера -- это всего лишь протокол. Ошибки HTTP предназначены для работы протокола, а не для логики приложений.


ПарамонМного буков он выдаёт, да бы отстоять свою позицию плюс нервишки шалят. ))

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

Позиция у меня абсолютно железная.

Ты ещё предложи использовать исключения в C# для передачи обычных сообщений внутри логики.
Это по сути абсолютно тоже самое.

hVosttТы ещё предложи использовать исключения в C# для передачи обычных сообщений внутри логики.

Вот это реально смешно!!! Я на стороне hVostt, потому что разделять ошибки HTTP протокола и бизнес-логики - это реально железобетонная "правильность"
...
Рейтинг: 0 / 0
12.10.2018, 05:18
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716531
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
CalabongaЗачем пониторить ошибки, которые не имеют отношения к бизнес логики? Мне кажется, что у вас, коллега, какая мания сложилась - всё "мониторить"... наверное это возрастное.

Мы просто друг друга не поняли. Я правильно понимаю, ошибки на стороне сервера (не обработанные исключения, невозможность выполнить операцию из-за внутренней ошибки, и т.д.), ты не оборачиваешь в OperationResult, а возвращаешь честный 500?

А ошибки протокола, типа неправильно составленный запрос, формат данных, невозможность адекватно сбиндить полученные данные в модель, это честный 400?

Ну и далее по списку, отсутствие ресурса - 404.
Отсутствие авторизации/доступа - 401/403.

Если углубляться, по REST, то 201 на созданный ресурс, 204 ответ типа "void" и т.д.

Ну и кеширование/перемещение ресурсов 3xx.
...
Рейтинг: 0 / 0
12.10.2018, 10:37
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716532
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
CalabongaЕще раз повторюсь, что я не оборачиваю ошибки HTTP протокола, напимер такие, как 500, потому что это невозможно да и смысла не имеет. Оборачиваются только ошибки БИЗНЕС-логики. Да и то, ошибка ошибке - рознь, всё хорошо в меру и с умом. :)

Да. У нас просто возник дискоммьюникейшен )
...
Рейтинг: 0 / 0
12.10.2018, 10:37
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716537
Дмитрий Мух
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дмитрий Мух
Участник
hVosttУ нас просто возник дискоммьюникейшен
На 14 страниц
...
Рейтинг: 0 / 0
12.10.2018, 10:46
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716555
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
Дмитрий МухhVosttУ нас просто возник дискоммьюникейшен
На 14 страниц

Ну хоть какое-то оживление )
...
Рейтинг: 0 / 0
12.10.2018, 11:14
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716566
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
Пошла сплошная лирика. Я вернусть к теме.

hVosttНет, отсутствие необходимого поля нивелирует остальной ответ.
Ну как можно не понять, что такой подход это глубокий маразм и смешивание мух и котлет.
По принципу, если на котлету села хоть одна муха, то это меняет весь раскалад.


hVosttПарамонhVostt,

Скажи про "402 Payment Required" платеж это бизнес логика или ошибка протокола?? )

Протокольный уровень.
Даже если спросить ребенка в яслях, он скажет, что оплата, это логика бизнеса.
Только бизнес логика решает, какие услуги платные а какие нет.
Слово Payment, никаким боком, ни к какому протоколу относится не может.
...
Рейтинг: 0 / 0
12.10.2018, 11:37
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716569
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
Calabongaстековерфлоу - полезный ресурс, но RFC - первична
Только нужно понимать, что там написано в RFC. Абсолютное большинство на стековерфлоу это понимают.
...
Рейтинг: 0 / 0
12.10.2018, 11:39
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716579
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
Petro123А что мы получаем смешивая 400 статус и 1500 кодов ошибок ошибочных запросов сервер <--> клиенты?
Получаем четкое разделение, успешный ответ сервера, и проблемный.
Сводим логику до простоты success и fail.
...
Рейтинг: 0 / 0
12.10.2018, 11:52
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716582
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
hVosttREST это не протокол и не стандарт. Это просто архитектурный стиль
Стиль, который использует протокол, со всеми его возможностями.
Ты просто не понимаешь рест, иначе не тащил бы сюда первые попавшиеся странички с логином.
...
Рейтинг: 0 / 0
12.10.2018, 11:57
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716585
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
Парамонон скажет, что оплата, это логика бизнеса.
код 402 вроде не используется? Чё об нём говорить?
...
Рейтинг: 0 / 0
12.10.2018, 12:02
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716586
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
ПарамонPetro123А что мы получаем смешивая 400 статус и 1500 кодов ошибок ошибочных запросов сервер <--> клиенты?
Получаем четкое разделение, успешный ответ сервера, и проблемный.
Сводим логику до простоты success и fail.
разделяем на каком уровне?
...
Рейтинг: 0 / 0
12.10.2018, 12:03
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716589
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
ПарамонПолучаем четкое разделение,
тут делим все коды и обрабатываем?
Код: c#
1.
2.
3.
if(xmlHttp.status == 200) {
		}else{
		}
...
Рейтинг: 0 / 0
12.10.2018, 12:10
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716590
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
ПарамонСводим логику до простоты success и fail.
у каждого слоя-модуля свой success и fail.
Увы(.
...
Рейтинг: 0 / 0
12.10.2018, 12:12
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716611
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
Petro123Парамонон скажет, что оплата, это логика бизнеса.
код 402 вроде не используется? Чё об нём говорить?
Используется.
...
Рейтинг: 0 / 0
12.10.2018, 12:40
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716612
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
Petro123ПарамонСводим логику до простоты success и fail.
у каждого слоя-модуля свой success и fail.
Увы(.
Увы, нет.
...
Рейтинг: 0 / 0
12.10.2018, 12:41
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716614
Парамон
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Парамон
Участник
Petro123ПарамонПолучаем четкое разделение,
тут делим все коды и обрабатываем?
Код: c#
1.
2.
3.
if(xmlHttp.status == 200) {
		}else{
		}


Нет. Читай ветку.
...
Рейтинг: 0 / 0
12.10.2018, 12:42
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716627
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
Парамон,
не отвечать твоё право). Продолжай.
...
Рейтинг: 0 / 0
12.10.2018, 12:54
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716818
WaspNewCore
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
WaspNewCore
Гость
Ох тыж ежик. Нифига себе вы тут тему размотали.

Пришли хоть к единому мнению то ? )
...
Рейтинг: 0 / 0
12.10.2018, 16:57
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716819
WaspNewCore
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
WaspNewCore
Гость
Чувствую поднял я сложную тему.
...
Рейтинг: 0 / 0
12.10.2018, 16:57
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716823
Фотография Shocker.Pro
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shocker.Pro
Участник
WaspNewCoreПришли хоть к единому мнению то ? )вот ты как автор темы и подведи итоги
...
Рейтинг: 0 / 0
12.10.2018, 17:12
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716831
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
WaspNewCoreЧувствую поднял я сложную тему.
ничего сложного. В архитектуре нету "золотой пули".
Мне нравится ответ Marcodor про 200, хотя у него лайков и поменьше чем на 400 )))
https://stackoverflow.com/questions/3290182/rest-http-status-codes-for-failed-validation-or-invalid-duplicate
Удачи!
...
Рейтинг: 0 / 0
12.10.2018, 17:22
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716833
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
WaspNewCore,

ПОднимай не тему, а вопросы.

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

Если ты придерживаешься этих же принципов, прислушайся к Парамону.

Если же ты собираешься извлекать от использования HTTP кодов определённую пользу, смотри мои рекомендации.
...
Рейтинг: 0 / 0
12.10.2018, 17:32
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716891
Addx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Addx
Участник
Petro123...
Мне нравится ответ Marcodor про 200, хотя у него лайков и поменьше чем на 400 )))
...


Ему следовало вставить в пост котиков ;)
...
Рейтинг: 0 / 0
12.10.2018, 19:51
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716906
love_bach
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
love_bach
Участник
Ну, я для себя вывод сделал. Но, я все же склонен к 204, если не найдено. Потому что 404 это, на мой взгляд, всеже ошибка уровня протокола, как тут и продвигают многие
...
Рейтинг: 0 / 0
12.10.2018, 20:33
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716907
love_bach
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
love_bach
Участник
love_bachНу, я для себя вывод сделал. Но, я все же склонен к 204, если не найдено. Потому что 404 это, на мой взгляд, всеже ошибка уровня протокола, как тут и продвигают многие

причем, именно ошибка
...
Рейтинг: 0 / 0
12.10.2018, 20:34
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716908
love_bach
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
love_bach
Участник
love_bachlove_bachНу, я для себя вывод сделал. Но, я все же склонен к 204, если не найдено. Потому что 404 это, на мой взгляд, всеже ошибка уровня протокола, как тут и продвигают многие

причем, именно ошибка

короче, моя чукотская броня не пробита
...
Рейтинг: 0 / 0
12.10.2018, 20:34
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716951
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
love_bachНу, я для себя вывод сделал. Но, я все же склонен к 204, если не найдено. Потому что 404 это, на мой взгляд, всеже ошибка уровня протокола, как тут и продвигают многие

Как раз если не найдено, это 404. Так как относится к URL.
...
Рейтинг: 0 / 0
12.10.2018, 22:28
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39716964
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
love_bachмоя чукотская броня не пробита
тогда на первую страницу))
21691147
...
Рейтинг: 0 / 0
12.10.2018, 23:25
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39717357
Calabonga
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Calabonga
Гость
hVosttCalabongaЗачем пониторить ошибки, которые не имеют отношения к бизнес логики? Мне кажется, что у вас, коллега, какая мания сложилась - всё "мониторить"... наверное это возрастное.

Мы просто друг друга не поняли. Я правильно понимаю, ошибки на стороне сервера (не обработанные исключения, невозможность выполнить операцию из-за внутренней ошибки, и т.д.), ты не оборачиваешь в OperationResult, а возвращаешь честный 500?

А ошибки протокола, типа неправильно составленный запрос, формат данных, невозможность адекватно сбиндить полученные данные в модель, это честный 400?

Ну и далее по списку, отсутствие ресурса - 404.
Отсутствие авторизации/доступа - 401/403.

Если углубляться, по REST, то 201 на созданный ресурс, 204 ответ типа "void" и т.д.

Ну и кеширование/перемещение ресурсов 3xx.

Да!!! Вот теперь всё правильно понято!!!
...
Рейтинг: 0 / 0
15.10.2018, 04:20
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39717358
Calabonga
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Calabonga
Гость
Теперь точно можно закрывать тему!
...
Рейтинг: 0 / 0
15.10.2018, 04:21
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39717373
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
Стопэ! Какой закрывать?
...
Рейтинг: 0 / 0
15.10.2018, 07:25
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39717443
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
skyANAСтопэ! Какой закрывать?

Больше подношений богу Флейма? )
...
Рейтинг: 0 / 0
15.10.2018, 11:11
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39717457
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
hVosttskyANAСтопэ! Какой закрывать?

Больше подношений богу Флейма? )
Нет, ты что. Серьёзная тема, надо до конца разобраться
...
Рейтинг: 0 / 0
15.10.2018, 11:28
| Ответить | Цитировать | Написать  
Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
    #39717485
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hVostt
Участник
skyANAНет, ты что. Серьёзная тема, надо до конца разобраться

Да ладно, так и скажи, что у тебя ещё не закончился попкорн
...
Рейтинг: 0 / 0
15.10.2018, 12:00
| Ответить | Цитировать | Написать  
370 сообщений из 370, показаны все 15 страниц
  все  
Форумы / ASP.NET [игнор отключен] [закрыт для гостей] / Какой-то стандартный подход для возврата на клиент ошибок/сообщений об ошибках ?
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?all=1&fid=18&tid=1355117]:
 0ms
get settings:
 9ms
get forum list:
 13ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 131ms
get topic data:
 12ms
get forum data:
 3ms
get page messages:
 372ms
get tp. blocked users:
 2ms
others: 268ms
total:  816ms
созд. / загр.: 816ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]