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

едином транспорте такое - оверхед дикий

но, как часто надо такое закладывать?

вот хороший вопрос

1. Почему дикий оверхед(нужны бенчмарки)? 2. Как вы отличаете что 403 прилетело с сервера, а не с коробки посередине?

1. по человеко-часам оверхед и без бенчей виден 2. по ошибке внутри

Чтобы разобрать ошибку внутри, надо всё равно смотреть payload. Если мы смотрим payload, то какая разница тогда на http-статусы?

А чего за коробка посередине?

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

Например, корп. фаерволл или dlp-система.

Т.е. это типичная история в каком-нибудь банке: на все клиентские машины раскатывается свой CA, а все https-ресурсы отствечивают сертификатом подписанным этим CA. Классический mitm + разбор что там в http у вас бегает. Всё это ради того чтобы сотрудник либо не слил какие-то важные данные, либо не притащил малварь на свою машину.

Ну если отдали 403, надо прекратить запросы и сообщить куда надо. Какая разница кто её отдал. Ну а если нужны детали, то есть тело. Есть content-type application/json, есть кастомные заголовки в конце концов. Но код 403 извольте не трогать.

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

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

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

а как клиент поймет, что именно означает 400, которую он получил?

код ошибок

код каких ошибок?

2. например, контракт ответа может включать статус-код. коробка - левый пейлоад, ваш сервис - в пейлоаде status: 403 или в целом по типам ошибок(если ваша "коробка" конфигается)

MY-SYSTEM-00003

чтобы по пути никто(апи гейтвей, реверс-прокси) его не поменял на себе угодный

А в чем проблема? Если сервер уже текст должен отдать, то клиент в запросе указывает нужный язык каким-нибудь Accept-Language. Сервер отвечает с кодом 400, устанавливает, например. Content-Type в application/json, и теле выплёвывает нужный json.

А почему он (не) поменяет? Проблема ведь в чём: мы одну и ту же информацию пытаемся передать и через статусы транспортного протокола, и через payload. И от одного из этих способов сигнализации можно избавиться.

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

А если клиент пришёл с Accept: application/xml - мы ему xml должны выплюнуть?

не, тут точно “bad request” 🙂

Я не понял, где надо её решать, поэтому и написал если. Если на клиенте, то всё тоже самое. Код http всё равно 400, тот же, например, json, а в теле самом Json внутренний код ошибки и фраза по-умолчанию. Клиент сам должен разрулить это.

Если серьёзно, я видел одно api, в которое можно сделать запрос с Content-Type: application/json и Accept: application/xml и сервис реально прожует json и выплюнет xml

Либо XML, либо ошибка 406/415, надо читать

а почему 400, а не 200?

swagger позволяет такое сконфигурить, и даже разумно выовет хендлеры

Осталось найти кодген который это умеет

А с чем связан оверхед? Вот у нас есть api, которое всегда отвечает 200, а в теле всегда есть поле status. Если ошибок нет, там 0. Если ошибка есть, то ещё поля message(где подробно описана причина ошибки) и debug(где лежит исходный запрос). В swagger описаны эти status, message, debug как отдельная сущность, которая подмешана через AllOf во все ответы api.

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

1. Если в транспорт не транслировать ошибки, то и дублировать не надо :) 2. Не надо паразитировать на статусах транспорта. У него свои ошибки, у нас - свои. 3. Никак. Swagger для этого не предназначен. Вообще, цирк начинается когда вам прилетает 30x код в ответ на ваш метод.