Какие данные об API можно найти в DevTools

Что проверяют

Умеете ли вы локализовать баг сами: понять, виноват фронтенд, бэкенд или данные, до того как отдавать задачу разработчику. Следом обычно просят показать, как по вкладке Network доказать, что ошибка на стороне сервера.

Как отвечать

Почти всё про API лежит во вкладке Network. По каждому запросу видно:

• URL, метод и статус: какой эндпоинт вызвался, GET или POST, что вернул сервер (200, 401, 422, 500) и не пришёл ли ответ из кэша;
• Headers: заголовки запроса и ответа. Здесь проверяют Authorization, Content-Type, Cache-Control, Set-Cookie и CORS-заголовки вроде Access-Control-Allow-Origin;
• Payload: параметры строки запроса и тело, которое ушло на сервер. Так видно, отправил ли фронтенд то, что ввёл пользователь;
• Preview и Response: тело ответа, обычно JSON. Его сравнивают с тем, что показано на экране;
• Timing: разбивка времени на очередь, DNS, соединение, TLS, ожидание первого байта и загрузку. Долгое ожидание первого байта указывает на сервер, а не на сеть;
• Initiator: какой скрипт и какая строка отправили запрос.

Полезные приёмы: фильтр Fetch/XHR, галочка Preserve log, чтобы запросы не пропадали при переходе, Disable cache, троттлинг сети, Copy as cURL для повтора запроса в терминале или импорта в Postman. Весь сеанс сохраняется в HAR-файл и прикладывается к баг-репорту. Для WebSocket есть вкладка Messages, токены и куки смотрят во вкладке Application, а ошибки CORS видны в Console.

Где спотыкаются

Смотрят только на статус. Ответ 200 с {"error": ...} в теле тоже баг, и его находят лишь в Response.

Не включают Preserve log и теряют запрос, после которого был редирект или перезагрузка страницы.

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