13 вопросов по теме «QA: HTTP и API» на собеседовании

Короткий ответ: Клиент (браузер, мобильное приложение) отправляет запрос, сервер обрабатывает его и возвращает ответ — модель request/response поверх HTTP. Полагаться на клиентскую валидацию нельзя, потому что клиент полностью под контролем пользователя: форму можно обойти через curl, Postman или DevTools и отправить на сервер любые данные. Поэтому сервер обязан валидировать сам, а QA проверяет оба слоя независимо.

Подробно:

1. Клиент — рисует UI, делает первичную валидацию для удобства (быстрый фидбек, без лишнего трафика), хранит токен.
2. Сервер — источник правды: проверяет права, валидирует тело, пишет в БД. Это единственный слой, которому можно доверять.
3. Что делает QA — не только кликает по UI, но и бьёт прямо в API в обход клиента: отправляет пустые/невалидные поля, чужой id, инъекции — и смотрит, что сервер их отбил (400/403), а не сохранил.

  КЛИЕНТ                         СЕРВЕР
 ┌────────┐   request  (HTTP)  ┌─────────┐
 │  UI    │ ─────────────────► │  API    │
 │ ✔ UX-  │                    │ ✔ обяза-│
 │ валид. │ ◄───────────────── │ тельная │──► БД
 └────────┘   response         │ валид.  │
     ▲  можно обойти:          └─────────┘
     └── curl / Postman / DevTools

⚠️ Частая ошибка: считать, что раз кнопка «Отправить» блокируется на форме, невалидные данные до сервера не дойдут. UI обходится за секунду — надёжная система проверяет всё на сервере.

Короткий ответ: Основные методы — GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS. Идемпотентны GET, PUT, DELETE, HEAD, OPTIONS (повторный запрос не меняет состояние сверх первого). POST не идемпотентен — повторный вызов может создать ещё один ресурс или выполнить действие второй раз. PATCH идемпотентность не гарантирует: зависит от реализации.

Подробно:

Идемпотентность — свойство метода, при котором N одинаковых запросов дают тот же итог на сервере, что и один. Это про побочный эффект на сервере, а не про тело ответа.

DELETE идемпотентен по эффекту: ресурс удалён после первого вызова и остаётся удалён — хотя второй вызов может вернуть 404 (это ок, состояние не изменилось).

⚠️ Частая ошибка: назвать PATCH идемпотентным по аналогии с PUT. PATCH {"balance": +10} при повторе прибавит ещё 10 — а PUT кладёт абсолютное значение и потому идемпотентен. Спорные случаи сверяйте с MDN / RFC 9110.

Короткий ответ: PUT заменяет ресурс целиком — вы присылаете полное представление, и сервер перезаписывает объект им. PATCH обновляет частично — вы присылаете только изменяемые поля. PUT всегда идемпотентен; PATCH идемпотентность не гарантирует.

Подробно:

1. PUT — полная замена. Тело должно содержать весь объект. Пропущенное поле трактуется как «этого поля нет» — сервер может обнулить его.
2. PATCH — дельта. Присылаете только то, что меняете; остальные поля остаются как были.
3. Связь с идемпотентностью. Повторный одинаковый PUT кладёт то же абсолютное состояние → идемпотентен. PATCH идемпотентен, только если операция абсолютная (set city=Москва), и НЕ идемпотентен, если относительная (increment).

PUT /users/42          → тело: {name, email, city} — весь объект
PATCH /users/42        → тело: {city: "Москва"} — только дельта

Что тестировать: отправьте PUT без части полей и проверьте, обнулились ли они (частый баг); отправьте один и тот же PATCH дважды и сверьте, что состояние совпадает.

⚠️ Частая ошибка: слать PUT с неполным телом, ожидая частичного обновления. По спеке PUT — это замена: отсутствующие поля можно потерять.

Короткий ответ: 401 Unauthorized — сервер не знает, кто вы: креды не переданы, токен просрочен или невалиден. 403 Forbidden — сервер знает, кто вы, но у вас нет прав на это действие. Одним предложением: 401 — «не вошёл», 403 — «вошёл, но нельзя».

Подробно:

Это ровно пара аутентификация vs авторизация, разнесённая по статус-кодам:

Сценарии:

• Дёрнули приватный эндпоинт вообще без заголовка Authorization → 401.
• Обычный пользователь зашёл в /admin с валидным токеном → 403.
• Токен был, но истёк → 401 (клиенту стоит рефрешнуть и повторить).

⚠️ Частая ошибка: возвращать 403 на просроченный токен. Клиент решит, что не хватает прав, и не станет рефрешить токен — хотя достаточно было переаутентифицироваться (401). Из соображений безопасности API иногда намеренно отдаёт 404 вместо 403, чтобы не палить существование ресурса — это отдельно проговаривают.

Короткий ответ: И 502, и 504 отдаёт прокси/шлюз (nginx, балансировщик, API gateway), когда проблема в апстриме за ним. 502 Bad Gateway — апстрим ответил, но чем-то невалидным (мусор, разорванное соединение, упавший процесс). 504 Gateway Timeout — апстрим вообще не ответил вовремя, шлюз устал ждать.

Подробно:

Важно различать всю пятёрку 5xx рядом:

 КЛИЕНТ ──► ПРОКСИ / GATEWAY ──► АПСТРИМ (app)
           (nginx, LB)
              │  апстрим прислал мусор  → 502
              │  апстрим молчит, таймаут → 504

Как QA: увидев 502/504, не заводите баг на фронт — смотрите в логи апстрима и прокси. 504 часто про долгий запрос/таймаут gateway, 502 — про упавший или перезапускающийся сервис.

⚠️ Частая ошибка: перепутать пары местами — «502 это таймаут». Таймаут это 504; 502 это невалидный ответ живого, но сломанного апстрима.

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

Подробно:

Что стоит помнить точечно:

• 201 Created — успешно создан ресурс (типичный ответ на POST).
• 204 No Content — успех без тела (часто DELETE).
• 304 Not Modified — кэш актуален, тело не пришлют.
• 429 Too Many Requests — сработал rate limit.

⚠️ Частая ошибка: отдавать 200 с телом {"error": ...}. Статус — часть контракта: ошибка должна ехать своим кодом (4xx/5xx), иначе клиенты и мониторинг считают запрос успешным.

Короткий ответ: REST — это архитектурный стиль поверх HTTP: ресурсы по URL, стандартные методы, stateless, обычно JSON. SOAP — строгий протокол: XML-конверт фиксированной структуры, контракт в WSDL, свой стек стандартов (WS-Security и др.). SOAP тяжелее, но живёт в банках и enterprise из-за жёстких контрактов, встроенной безопасности и массы легаси-интеграций, которые никто не будет переписывать.

Подробно:

Почему банки держат SOAP: WSDL даёт машинно-проверяемый контракт, WS-Security и транзакционность прописаны в стандарте, а замена работающих межбанковских интеграций — это риск, который не окупается.

⚠️ Частая ошибка: назвать REST протоколом (это стиль) или поставить знак равенства REST = JSON. REST не привязан к формату — просто JSON стал де-факто выбором.

Короткий ответ: Бью прямо в эндпоинт из Postman/curl и проверяю не только статус, но и тело, схему, заголовки, авторизацию, негативные сценарии и время ответа. UI при этом не нужен — API тестируется как отдельный контракт.

Подробно:

1. Статус-код — 200/201/204 на успех, ожидаемые 4xx на невалидный ввод.
2. Тело и схема — поля на месте, типы верные, нет лишних/утёкших полей; валидирую по JSON-схеме, а не глазами.
3. Заголовки — Content-Type, кэш, Location на 201.
4. Авторизация — без токена → 401; чужой токен → 403.
5. Негативные кейсы — нет обязательного параметра, неверный тип, дубликат, граничные значения.
6. Производительность — время ответа в рамках SLA.
7. Chaining — вытащить токен/id из одного ответа и подставить в следующий запрос.

// Postman: тест ответа + сохранение токена для следующего запроса
pm.test("status 200", () => pm.response.to.have.status(200));
pm.test("has token", () => pm.expect(pm.response.json().token).to.exist);
pm.collectionVariables.set("token", pm.response.json().token);
// далее в заголовке: Authorization: Bearer {{token}}

⚠️ Частая ошибка: ограничиться assert 200. Сервис может вернуть 200 с пустым/битым телом или лишними полями — без проверки схемы и негативных кейсов это проходит мимо.

Короткий ответ: Аутентификация — доказать, кто ты (логин/пароль, код, токен); система убеждается в личности. Авторизация — что тебе можно (роли, скоупы, права); система проверяет доступ. Сначала аутентификация, потом авторизация.

Подробно:

1. Аутентификация (AuthN) — «кто ты?». На входе креды, на выходе — сессия или токен (например, JWT). Провал → 401.
2. Авторизация (AuthZ) — «что тебе разрешено?». Проверяются роли/скоупы, часто зашитые в клеймы JWT. Провал → 403.
3. Порядок — нельзя авторизовать неизвестного: сперва подтверждаем личность, затем сверяем права на конкретное действие.

⚠️ Частая ошибка: путать термины как синонимы. Валидный токен (аутентификация пройдена) не значит доступ ко всему — обычный пользователь с корректным токеном на /admin должен получить 403.

Короткий ответ: TCP handshake — трёхэтапное рукопожатие SYN → SYN-ACK → ACK, которым клиент и сервер устанавливают соединение до передачи каких-либо HTTP-данных. HTTPS — это HTTP поверх TLS: после TCP-рукопожатия идёт ещё TLS-рукопожатие (проверка сертификата, обмен ключами), и дальше весь HTTP-трафик шифруется.

Подробно:

1. TCP handshake — гарантирует, что обе стороны готовы: SYN (клиент), SYN-ACK (сервер), ACK (клиент). Только после этого соединение открыто.
2. TLS handshake (только HTTPS) — поверх TCP: сервер шлёт сертификат, стороны договариваются о ключах, включается шифрование.
3. HTTP vs HTTPS — HTTP шлёт данные открытым текстом (порт 80); HTTPS — зашифрованно (порт 443), защита от перехвата и подмены.

         TCP handshake            TLS handshake (только HTTPS)
Клиент ── SYN ─────►
       ◄─ SYN-ACK ──  Сервер
       ── ACK ──────►
       ── ClientHello ─────►
       ◄─ сертификат, ключи ─  Сервер
       ══ шифрованный HTTP ══►

⚠️ Частая ошибка: валить TCP- и TLS-рукопожатия в одно. Это два отдельных этапа: сначала устанавливается TCP-соединение, и только затем поверх него — TLS. HTTPS добавляет второй шаг, не заменяя первый.

Короткий ответ: Открываю DevTools: вкладка Console — есть ли JS-ошибка до/во время клика, и вкладка Network — ушёл ли вообще запрос, с каким статусом и телом. Если запрос не уходит или падает в JS — баг на клиенте; если запрос корректный, а ответ плохой (5xx / неверное тело) — баг на сервере.

Подробно:

1. Console — красная JS-ошибка при клике часто означает, что обработчик упал и до сети дело не дошло → клиент.
2. Network — смотрю, появился ли запрос. Нет запроса → клиент (не навесился хендлер, упал JS). Запрос есть → смотрю статус и тело.
3. Разбор запроса/ответа — payload корректный, а ответ 500/битый → сервер. Payload кривой (не те поля) → клиент собрал запрос неправильно.
4. Подтверждение — повторяю запрос в curl/Postman с тем же телом: воспроизвелось без UI → сервер, значит фронт ни при чём.

Клик
 │
 ├─ JS-ошибка в Console? ─── да ─► КЛИЕНТ
 │
 ├─ Запрос ушёл (Network)? ─ нет ─► КЛИЕНТ
 │
 └─ Ответ 5xx / битое тело? ─ да ─► СЕРВЕР
        payload кривой? ───── да ─► КЛИЕНТ

⚠️ Частая ошибка: сразу писать «баг на бэке», не открыв Network. Если запрос вообще не ушёл — виноват клиент, и бэкендеру там делать нечего.

Короткий ответ: HTTP-запрос — это request line (метод, путь, версия), заголовки и опциональное тело. HTTP-ответ — status line (версия, статус-код, причина), заголовки и тело. Обе структуры разделяют заголовки и тело пустой строкой.

Подробно:

• Request line — метод (GET/POST), путь (/users/42), версия (HTTP/1.1).
• Заголовки — метаданные: Host, Authorization, Content-Type, Accept.
• Тело — данные запроса (JSON у POST/PUT); у GET обычно пустое.
• Status line (ответ) — версия, код (200), причина (OK).

POST /api/login HTTP/1.1          ← request line
Host: api.example.com             ← заголовки
Content-Type: application/json
                                  ← пустая строка
{ "email": "a@b.io", "pwd": "…" } ← тело

HTTP/1.1 200 OK                   ← status line
Content-Type: application/json    ← заголовки

{ "token": "eyJhbGciOi…" }        ← тело

Это фундамент для чтения вкладки Network и работы в Postman: там вы видите ровно эти части.

⚠️ Частая ошибка: путать заголовки и тело — например, слать токен в теле вместо заголовка Authorization, или искать данные POST в query-строке, а не в body.

Короткий ответ: Проверяю idempotency key: клиент присылает уникальный ключ в заголовке (например, Idempotency-Key), и повторный POST с тем же ключом не создаёт второй платёж, а возвращает результат первого. Тестирую дубли, обрывы сети и параллельные ретраи — именно там всплывают двойные списания.

Подробно:

1. Дубль запроса — два одинаковых POST с одним ключом → один платёж, второй ответ идентичен первому.
2. Обрыв после списания — деньги списались, но ответ не дошёл; клиент ретраит с тем же ключом → повторного списания нет.
3. Параллельные ретраи — два запроса с одним ключом одновременно (гонка) → создаётся ровно один платёж, второй ждёт/получает тот же результат.
4. Другой ключ — тот же платёж, но новый ключ → это уже новый платёж (проверяю, что ключ реально влияет).
5. Проверка на стороне БД — после серии ретраев в таблице ровно одна транзакция.

Клиент                         API
  │ POST /pay  Key: abc-123 ──► списание ✔, ответ теряется ✗
  │ (таймаут, сеть оборвалась)
  │ POST /pay  Key: abc-123 ──► тот же ключ → возврат прежнего
  │                             результата, второго списания НЕТ

⚠️ Частая ошибка: считать, что «POST сам разберётся» или что хватит уникального order_id в теле. Без явного idempotency key и его проверки на сервере ретрай при обрыве сети даёт двойное списание — классический финтех-инцидент.