Stage 5. Browser to Server Flow
Когда пользователь нажимает кнопку в веб-интерфейсе, запрос проходит длинную цепочку до того, как бизнес-логика API вообще начнет выполняться. Новички часто проверяют только код endpoint-а и не видят остальные слои, из-за чего диагностика “случайных” ошибок затягивается. На практике важно понимать путь запроса целиком: DNS, TLS, заголовки, прокси, браузерные политики, кеш.
Сначала браузер определяет origin и базовые политики безопасности. Затем разрешается доменное имя через DNS, устанавливается TCP/TLS-соединение, формируется HTTP-запрос с заголовками, cookie и телом. Далее запрос проходит через внешние слои инфраструктуры: CDN, reverse proxy, API-gateway. Только после этого API возвращает статус, заголовки и тело ответа, а браузер решает, можно ли отдать данные JavaScript-коду на странице.
Ключевая мысль: 200 OK от API не гарантирует успешный пользовательский сценарий. Браузер может заблокировать доступ к ответу из-за CORS-политики, политики cookie или других ограничений. Поэтому ситуация “в Postman работает, в браузере нет” абсолютно типична и не означает, что пользователь “ошибся”.
Заголовки часто важнее тела ответа. Origin, Authorization, Cookie, Cache-Control, ETag, Vary и служебные correlation-заголовки определяют поведение всей цепочки. Если один из них потерян или искажен на уровне прокси, вы получите дефект, который выглядит как “баг приложения”, хотя причина сетевого уровня.
X-Request-Id: 3f9c2d7a
Сквозной request id — один из самых дешевых и полезных инструментов поддержки. Когда одинаковый идентификатор проходит через клиент, gateway и сервис, расследование инцидента перестает быть гаданием. Вы можете точно сопоставить, что было отправлено, что дошло до сервера и какой ответ вернулся на каждом этапе.
Кеш — ещё один частый источник путаницы. Браузерный и промежуточный кеш может отдавать старые данные, если заголовки кеш-политики заданы неявно или неверно. В таких случаях команда часто тратит время на поиск “проблемы в базе”, хотя фактически возвращается устаревшая репрезентация.
Полезная дисциплина для отладки — фиксированный порядок проверки. Сначала смотрим DevTools (Network + Headers + Timing), затем проверяем preflight/основной запрос, затем сверяем X-Request-Id в backend-логах, затем анализируем бизнес-логику. Если начинать с конца (с контроллера), легко пропустить проблему до уровня приложения.
Практический сценарий
Команда видит, что endpoint отвечает 200, но SPA не обновляет экран. Разбор показывает: preflight-запрос OPTIONS возвращает неполный набор CORS-заголовков, и браузер блокирует чтение ответа. Сервер формально “работает”, но пользовательский поток сломан. После исправления заголовков и добавления проверки этого сценария в e2e-тестах проблема исчезает. Этот пример хорошо показывает, что качество веб-API зависит от всей цепочки, а не только от бизнес-метода.