КУПОНЫ
ВЫГОДНЫЙ НАБОР

Интерактивная шпаргалка по API

Ваш гид по современным видам API. Наводите курсор на выделенные элементы в примерах кода, чтобы увидеть подробные подсказки.

Основы API для тестировщика

Ключевые концепции, которые нужно знать перед началом работы.

Что такое API?

API (Application Programming Interface) — это программный интерфейс, который позволяет приложениям обмениваться данными и функциональностью. Представьте его как официанта в ресторане: вы (клиент) делаете заказ (запрос), официант передает его на кухню (сервер), а затем приносит вам готовое блюдо (ответ).

Зачем тестировать API?

Тестирование API позволяет проверить бизнес-логику приложения в изоляции от UI. Это ключевой этап для обеспечения качества, так как:

  • Надежность: Тесты API стабильнее и быстрее UI-тестов.
  • Раннее обнаружение багов: Ошибки в логике находятся до того, как они "доберутся" до интерфейса.
  • Покрытие: Можно проверить граничные случаи и сценарии, которые сложно или невозможно воспроизвести через UI.

Что именно тестировать в API?

  • Корректность данных: Соответствие ответа ожидаемой структуре (схеме) и значениям.
  • Коды ответа HTTP: Проверка, что сервер возвращает правильные статусы (200 OK, 201 Created, 400 Bad Request, 404 Not Found, 500 Internal Server Error и т.д.).
  • Авторизация и безопасность: Доступ к эндпоинтам с разными правами, защита от инъекций.
  • Производительность: Время ответа сервера под нагрузкой.
  • Обработка ошибок: Корректность и информативность сообщений об ошибках.

REST (Representational State Transfer)

Самый распространенный архитектурный стиль для создания веб-сервисов. Взаимодействие строится вокруг ресурсов и стандартных HTTP-методов.

Ключевые принципы REST

  • Клиент-сервер: Четкое разделение: клиент отвечает за интерфейс, сервер — за логику и хранение данных.
  • Stateless (Отсутствие состояния): Каждый запрос от клиента должен содержать всю информацию, необходимую для его выполнения. Сервер не хранит состояние клиента между запросами.
  • Кэширование: Ответы сервера должны помечаться как кэшируемые или некэшируемые.
  • Единообразие интерфейса: Взаимодействие происходит через ресурсы, идентифицируемые по URL. Для манипуляции ресурсами используются стандартные HTTP-методы.

HTTP Методы и Идемпотентность

  • GET: /users/123 — получить пользователя.
  • POST: /users — создать пользователя.
  • PUT: /users/123 — заменить данные пользователя.
  • PATCH: /users/123 — обновить имя пользователя.
  • DELETE: /users/123 — удалить пользователя.

Пример JSON ответа

{
  "id": 123,
  "name": "Анна",
  "isActive": true,
  "desk": null,
  "tags": [ "user", "reader" ],
  "address": { "city": "Moscow" }
}

Что тестировать в REST?

  • Валидация JSON-схемы: Проверка соответствия структуры ответа документации (например, OpenAPI/Swagger).
  • Проверка HTTP-статусов: Убедиться, что на корректный запрос приходит 2xx, на некорректный - 4xx, а при сбое сервера - 5xx.
  • CRUD-операции: Проверить всю цепочку: создали (POST), прочитали (GET), обновили (PUT/PATCH), удалили (DELETE).
  • Пагинация и фильтрация: Корректность работы параметров вроде `?page=2&limit=10&status=active`.

GraphQL

Язык запросов для API, который позволяет клиенту запрашивать только те данные, которые ему нужны, решая проблему избыточной или недостаточной загрузки данных.

Ключевые принципы

  • Один эндпоинт: Все запросы обычно идут на один URL (например, `/graphql`).
  • Строгая типизация: Все данные в API описаны с помощью схемы (Schema Definition Language, SDL).
  • Декларативность: Клиент точно описывает, какие данные и в какой структуре он хочет получить.

Основные операции

  • Query: Запрос данных (аналог GET в REST).
  • Mutation: Изменение данных (создание, обновление, удаление — аналог POST/PUT/DELETE).
  • Subscription: Подписка на изменения данных в реальном времени (использует WebSockets).

REST (Over-fetching)

GET /users/123

// Вернется весь объект:
{
  "id": 123,
  "name": "Анна",
  "email": "anna@a.com",
  "bio": "...",
  "posts": [...]
}

GraphQL (Точные данные)

query GetUserName {
  user(id: 123) {
    name
  }
}

// Вернется только то, что просили:
{ "data": { "user": { "name": "Анна" } } }

Что тестировать в GraphQL?

  • Соответствие схеме: Запросы и ответы должны соответствовать SDL. Интроспекция схемы помогает в автоматизации.
  • Обработка ошибок: GraphQL всегда возвращает статус 200 OK, даже если в запросе есть ошибка. Сами ошибки нужно искать внутри JSON-ответа, в поле `errors`.
  • Глубина и сложность запросов: Тестирование на слишком "глубокие" или сложные запросы, которые могут вызвать проблемы с производительностью.
  • Мутации: Проверка, что мутации корректно изменяют данные и возвращают ожидаемый результат.

WebSocket

Протокол, обеспечивающий постоянное, двунаправленное (full-duplex) соединение между клиентом и сервером. Идеален для чатов, игр и онлайн-торговли.

Симуляция WebSocket-соединения

В DevTools браузера взаимодействие по WebSocket можно увидеть во вкладке Network → Socket. Сообщения отображаются в реальном времени.

Пинг-понг и коды закрытия

Чтобы поддерживать соединение и проверять, что клиент "на связи", используется механизм ping-pong. Сервер периодически отправляет клиенту `ping`-фрейм, на который тот должен ответить `pong`-фреймом. Если ответ не приходит, соединение считается разорванным.

  • 1000: Успешное завершение.
  • 1001: Одна из сторон "уходит".
  • 1002: Ошибка протокола.
  • 1003: Неподдерживаемый тип данных.
  • 1006: Нештатное закрытие.
  • 1008: Нарушение политики.

Что тестировать в WebSocket?

  • Handshake ("рукопожатие"): Корректность установки соединения (получение статуса 101 и правильных заголовков).
  • Отправка и получение сообщений: Проверка, что сообщения доходят от клиента к серверу и наоборот без искажений.
  • Обработка разрыва соединения: Что происходит, если одна из сторон "отвалилась"? Есть ли механизм переподключения? Корректно ли отправляется код закрытия?
  • Механизм Ping-Pong: Проверить, что соединение не разрывается при бездействии.
  • Нагрузка: Как система ведет себя при большом количестве одновременных подключений и интенсивном обмене сообщениями.

gRPC (Google Remote Procedure Call)

Современный высокопроизводительный фреймворк от Google для вызова удаленных процедур. Использует Protocol Buffers и HTTP/2, что делает его крайне быстрым.

Ключевые принципы

  • Contract-First: Взаимодействие описывается в `.proto` файле (контракте).
  • Protocol Buffers: Эффективный бинарный формат сериализации данных.
  • HTTP/2: Работает поверх HTTP/2 для высокой производительности.

Пример .proto контракта

syntax = "proto3";
package user.v1;

service UserService {
  rpc GetUser (UserRequest) returns (UserResponse);
}

message UserRequest {
  int64 id = 1;
}
message UserResponse {
  int64 id = 1;
  string name = 2;
}

Как работает gRPC запрос? (Простыми словами)

Представьте, что у вас есть два человека, говорящих на разных языках, и строгий словарь (`.proto`-файл).

  1. Клиент: "Хочу получить пользователя с ID 123". Эта фраза записывается не словами, а специальными, очень короткими кодами из словаря. Получается "сжатое" бинарное сообщение.
  2. Транспорт (HTTP/2): Это бинарное сообщение отправляется по сверхскоростному шоссе HTTP/2.
  3. Сервер: Получает "сжатое" сообщение и, используя тот же словарь, переводит его обратно на свой язык: "Ага, клиент хочет пользователя с ID 123".
  4. Обработка: Сервер находит пользователя и готовит ответ.
  5. Обратный путь: Ответ снова "сжимается" в бинарный код по словарю и мчится обратно к клиенту по тому же шоссе. Клиент расшифровывает его и получает готовый результат.

Ключевая идея: вместо обмена длинными текстовыми JSON-ами, gRPC обменивается компактными бинарными сообщениями, что делает его очень быстрым.

Что тестировать в gRPC?

  • Соответствие контракту: Проверка, что клиент и сервер работают по одной и той же версии `.proto` файла.
  • Корректность сериализации/десериализации: Убедиться, что данные не искажаются при преобразовании в бинарный формат и обратно.
  • Обработка gRPC статусов: Проверка кодов ошибок (например, `NOT_FOUND`, `ALREADY_EXISTS`, `PERMISSION_DENIED`).
  • Стриминг: Тестирование корректной работы потоковой передачи данных (если используется).

SOAP (Simple Object Access Protocol)

Строгий протокол для обмена структурированными сообщениями в формате XML. Часто используется в enterprise-системах, где важна надежность и безопасность.

<soap:Envelope xmlns:soap="...">
  <soap:Header></soap:Header>
  <soap:Body>
    <m:GetUser>
      <m:UserId>123</m:UserId>
    </m:GetUser>
  </soap:Body>
</soap:Envelope>

<wsdl:definitions>
  <wsdl:types> ... </wsdl:types>
  
  <wsdl:message name="GetUserRequest">
    <wsdl:part name="parameters" element="tns:GetUser"/>
  </wsdl:message>
  
  <wsdl:portType name="UserPortType">
    <wsdl:operation name="GetUser">
      <wsdl:input message="tns:GetUserRequest"/>
      <wsdl:output message="tns:GetUserResponse"/>
    </wsdl:operation>
  </wsdl:portType>
  
  <wsdl:binding name="UserBinding" type="tns:UserPortType"> ... </wsdl:binding>
  
  <wsdl:service name="UserService"> ... </wsdl:service>
</wsdl:definitions>

<xs:schema targetNamespace="...">
  <xs:element name="GetUserRequest">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="UserId" type="xs:int"/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
</xs:schema>

Базовые правила синтаксиса XML

  • Структура: Документ должен иметь один корневой элемент. Все остальные элементы должны быть вложены в него.
  • Закрывающие тэги: Каждый открывающий тэг <tag> должен иметь соответствующий закрывающий тэг </tag>.
  • Чувствительность к регистру: Тэги <User> и <user> — это два разных тэга.
  • Экранирование символов: Спецсимволы нужно заменять на их сущности:
    • &lt; вместо <
    • &gt; вместо >
    • &amp; вместо &
    • &quot; вместо "
    • &apos; вместо '
  • Комментарии: Комментарии заключаются в <!-- ... -->.

Что тестировать в SOAP?

  • Валидация по WSDL и XSD: Проверка того, что запросы и ответы строго соответствуют контракту.
  • Обработка ошибок (Faults): SOAP имеет специальный элемент `` для сообщений об ошибках. Нужно проверять его корректное формирование.
  • Проверка пространств имен (namespaces): Ошибки в `xmlns` могут сделать весь запрос невалидным.
  • Тестирование безопасности: Если используется WS-Security, необходимо проверять шифрование и подписи сообщений.
© 2025 Artsiom Rusau QA Life
Контакты
telegram: @artsiom_qa
Другие активности
Все остальные ссылки и активности ищите здесь
Документы
Политика конфиденциальности
Согласие на обработку перс. данных
Публичная оферта