ПарамонStakoverflow комьюнити косячат, Amazon, MS косячат.
Вам кажется, что все вокруг дураки?
Это давно началось?

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


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

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

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

Так-то можно всегда 500 отдавать и клиента научить не париться. Чё такого.

Парамон1. Стандартный подход есть.

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


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

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


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

Непонимание термина "ошибка".

Парамон,

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

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

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

Посмотри у Амазона.... Ясно. Я ещё раз объясню, как приеду. Но явно не для вас. Почему-то
по этой теме вы не способны аргументировано вести диалог. Понятия не имею с чем это связано.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ПарамонВсего лишь поддерживаю стиль общения собеседника, но в своём глазу ведь бревно не видно.

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


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

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


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

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

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


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

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

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

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

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

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

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

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

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

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

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

ПарамонВсе это деление на протокол и логику надуманно.

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



Я же говорил. Детский сад и поле чудес. Тебе надо на форум модников и фломастеров.

ПарамонВ двух словах. Если клиент ошибся с бизнес логикой, то сервис хвоста вернёт статус 200 и сообщение с ошибкой. Все.

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


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

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

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

Ты ещё предложи использовать исключения в C# для передачи обычных сообщений внутри логики.
Это по сути абсолютно тоже самое.

ViPRosПри ошибках логики надо возвращать статус 402 :)
(А так хвост прав - 200 и все дела - HTTP сработал как положено)

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

И потом, я ещё не раскрывал тему с точки зрения тестирования.
Но учитывая мрак в головах, думаю это бессмысленно.

stenford,

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

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