ПРО АНАЛИТИКА | СИСТЕМНЫЙ АНАЛИТИК | АЛЕКСАНДР НЕЗДЕМИНА
Образование · 8 июня 2026 г.
Мне тут задали интересный вопрос ребята на курсе, делюсь ответом и с вами 😉 — 8 июня 2026 г. в 14:12:49.480
Мне тут задали интересный вопрос ребята на курсе, делюсь ответом и с вами 😉 Ученики тренировались смотреть вызовы в DevTools и некоторые сайты возвращают 200 ОК, а в теле реальную ошибку с кодом. Соответсвенно возникают вопросы - Почему так? Это ошибка проектирования или нет? Сказать ошибка это или нет - нельзя наверняка, потому что это зависит от многих факторов. Вот давайте с ними и разберемся, в каких случаях 200 и ошибка внутри это ок, а в каких нет. ➖➖➖ Какие могут быть причины, почему появляется 200 ОК при ошибке? 1️⃣ В компании есть какое-то легаси или зоопарк систем. Этот пункт подходит под формулировку «так исторически сложилось». Раньше так проектировали системы для поддержки многих UI или потому что переходили, например, с SOAP на REST и из-за этого обработку решили не менять, так как за годы обрасли большим количеством потребителей, которые надо перестраивать, а это very дорого. 2️⃣ Используют технологию у которой свои правила, а HTTP используют, как транспорт. Например, для SOAP, JSON-RPC, GraphQL такое поведение норма. Эти протоколы просто используют HTTP как транспорт. 3️⃣ Осознанное разделение транспорта и бизнес логики. Бывают кейсы, когда команда осознанно, принимает решение, что HTTP-коды отвечают за транспорт. Например, дошёл запрос, авторизован ли, нашёлся ли эндпоинт, а бизнес логику помещают в тело ответа. Например, указывают "недостаточно средств". Это, конечно, не по REST, но не все придерживаются этого стиля. 4️⃣ Просто передача кода от внешней системы. Бывают кейсы, когда 200 прилетел не от бэка, а от шлюза, балансировщика или кривого API Gateway. Бэк возвращает 500, а наружу уже отправляется 200 с телом ошибки. Если такой кейс возникает, то это большие вопросы к настройки инфры. 5️⃣ Просто кривой дизайн. Такое бывает, когда разработчики просто решили делать так. ➖➖➖ Поэтому, если вы смотрите чужие реализации, например, для анализа конкурентов и хотите посмотреть, как они реализовали то или иное поведение своего приложения - просто не удивляйтесь. Ну и когда проектируете свое решение, всегда смотрите, как принято в компании, и выясняйте почему уже реализовано так, а не по канонам какого-то стиля. Ставь 🔥, если было полезно