Тестирование Web и API

1xx — информационные, 2xx — успех (200 OK, 201 Created, 204 No Content), 3xx — перенаправление (301/302), 4xx — ошибка клиента (400 Bad Request, 401, 403, 404), 5xx — ошибка сервера (500, 502, 503). Первая цифра говорит, кто виноват: клиент прислал что-то неверное (4xx) или сервер не справился (5xx).

API — это контракт, позволяющий системам обмениваться данными без графического экрана: клиент шлёт запрос, сервер возвращает структурированный ответ. Тестировать его отдельно быстрее, можно начать до готовности UI, это изолирует баги бэкенда от багов интерфейса и упрощает покрытие негативных и граничных случаев и автоматизацию.

GET читает данные и передаёт параметры в query-строке URL (?a=1&b=2), поэтому он кэшируемый, идемпотентный, ограничен по длине и виден в логах. POST создаёт или отправляет данные в теле запроса, не кэшируется и не идемпотентен.

В клиент-серверной архитектуре клиент посылает запрос, сервер обрабатывает его и возвращает ответ; они общаются по сетевому протоколу, например HTTP. Клиентом может быть всё, что инициирует запросы — браузер, мобильное приложение, другой backend-сервис, CLI-утилита или IoT-устройство, а не только человек у экрана.

Четыре базовых метода соответствуют CRUD: GET читает ресурс, POST создаёт новый, PUT заменяет или полностью обновляет, DELETE удаляет. PATCH применяет частичное обновление. GET передаёт параметры в query-строке URL, а POST, PUT и PATCH — данные в теле запроса.

Идемпотентность означает, что повтор одного запроса любое число раз оставляет сервер в том же состоянии, что и однократная отправка. GET, PUT, DELETE и HEAD идемпотентны; POST — нет, так как каждый вызов создаёт новый ресурс. Идемпотентность не требует одинаковых ответов — только одинакового итогового состояния.

Используйте ресурсы-существительные во множественном числе и префикс версии: POST /v1/exchanges/{id}/users → 201 Created (создание на бирже); GET /v1/users → 200 OK (все пользователи); GET /v1/exchanges/{id}/users/{userId} → 200 OK (один пользователь на одной бирже); выдача доступа — это создание ресурса доступа: POST /v1/exchanges/{id}/users/{userId}/access → 201 либо PUT членства → 200. Дизайн RESTful, потому что ресурсы — существительные в URL, HTTP-глагол несёт действие, статус-коды используются верно, а дизайн без состояния и единообразно версионирован.

Распространённые схемы: Basic Auth (base64 от учётных данных в заголовке, безопасен только по HTTPS), токены Bearer/JWT, API-ключи, OAuth 2.0, Digest, сессионные cookies и mTLS. Различаются тем, где живёт секрет, истекает ли он и делегируется ли доступ.

В JSON шесть типов значений: строка (всегда в двойных кавычках), число, булево (true/false), null, объект {} и массив []. Ключи должны быть строками в двойных кавычках. Формат запрещает висячие запятые, комментарии, одинарные кавычки и ведущие нули, а числа используют точку как десятичный разделитель.

Точный ответ — 401 Unauthorized: запросу не хватает валидных учётных данных. 403 Forbidden — другое: пользователь аутентифицирован, но ему не разрешено. Некоторые API отдают 400 Bad Request, если само тело некорректно, но для верно оформленных, но неправильных данных правильно 401.

HTTPS — это HTTP поверх TLS: трафик шифруется, сервер аутентифицируется сертификатом, а данные защищены от подмены. Обычный HTTP — открытый текст, доступный любому на пути. Оба имеют одну структуру сообщения: строка статуса, заголовки, тело.

Он читает заголовки запроса, которые шлёт клиент. User-Agent несёт браузер, ОС и устройство; Accept-Language — предпочитаемый язык; IP клиента и cookies добавляют контекст. Сервер использует их для согласования контента — отдавая локализованную страницу или ответ под устройство — поэтому один URL может вернуть разный контент разным клиентам.

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

При синхронном взаимодействии вызывающий блокируется и ждёт ответа, прежде чем продолжить. При асинхронном вызывающий сразу продолжает, а результат приходит позже через callback, опрос, webhook или очередь сообщений. Для тестировщика async привносит таймауты, отложенную согласованность и гонки, которых нет в синхронных потоках.

Kafka (брокер сообщений, передающий сообщения между сервисами) группирует сообщения в partitions, а consumer groups читают их параллельно. Дубли появляются при доставке at-least-once: consumer обработал сообщение, но упал до коммита offset, и оно доставляется повторно. С ними борются дедупликацией — идемпотентной обработкой по уникальному ключу сообщения или idempotent producer, чтобы повторная обработка не давала лишнего эффекта. At-most-once избегает дублей, но рискует терять сообщения.

Переменные позволяют переиспользовать значения (URL, токены, id) между запросами вместо их жёсткой записи. Postman разрешает scope по правилу «уже — побеждает»: Local > Data > Environment > Collection > Global, так что локальная переменная бьёт глобальную с тем же именем. При запуске коллекции сначала идёт pre-request скрипт уровня коллекции, затем pre-request скрипт каждого запроса перед его отправкой.

WSDL (Web Services Description Language) — это XML-документ, формально описывающий SOAP-веб-сервис: его операции, сообщения и типы данных, которыми они обмениваются, а также эндпоинты и привязки. Это машиночитаемый контракт, который клиент читает, чтобы точно знать, как вызывать сервис, так что инструменты могут генерировать клиентские заглушки автоматически.

JSON легче и ложится прямо на объекты ключ-значение и массивы, родной для JavaScript и по умолчанию без схемы. XML многословнее, использует вложенные теги с атрибутами и пространствами имён, поддерживает комментарии и проверяется по XSD-схеме. Сервисы SOAP используют XML, а REST-API чаще JSON.

Блок нарушает несколько правил JSON: строковое значение без кавычек (73bf37d59d), ведущий ноль (01), запятая как десятичный разделитель (20,5 должно быть 20.5), ключ без кавычек (title_font_style), висячая запятая после "mobile" и пропущенная закрывающая } у объекта {type, title} перед его ]. Кавычки у "false" допустимы, но, вероятно, должно быть булево false.