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

API — это интерфейс взаимодействия между системами, который определяет, как одна система может отправлять запросы и получать ответы от другой. API описывает: Какие эндпоинты доступны (URL). Какие методы используются (GET, POST и т.д.). Какие данные нужно передавать. Какие ответы можно получить. API позволяет разделить систему на части: Фронтенд (интерфейс). Бэкенд (логика). Внешние сервисы. Пример: Фронтенд отправляет POST /login с email и паролем. Бэкенд проверяет данные и возвращает токен или ошибку.

HTTP — это протокол прикладного уровня, по которому клиент и сервер обмениваются данными. Структура HTTP-запроса: URL — адрес ресурса. Method — тип операции (GET, POST и т.д.). Headers — метаданные (например, Authorization, Content-Type). Body — тело запроса (обычно JSON). Структура HTTP-ответа: Status code — результат запроса. Headers — служебная информация. Body — данные ответа. Пример: POST /login Headers: Content-Type: application/json Body: { "email": "test@test.com", "password": "123456" } 200 OK { "token": "abc123" }

GET — получение данных (не изменяет состояние). POST — создание ресурса. PUT — полное обновление ресурса. PATCH — частичное обновление. DELETE — удаление ресурса. Особенности: GET должен быть безопасным и идемпотентным. PUT — идемпотентный. POST — не идемпотентный. Пример: GET /users — получить список пользователей. POST /users — создать пользователя. PUT /users/1 — заменить данные пользователя. PATCH /users/1 — изменить только часть данных.

Идемпотентность — это свойство операции давать одинаковый результат при многократном выполнении. GET, PUT, DELETE — идемпотентны. POST — нет. Это важно для: Повторных запросов. Обработки сетевых ошибок. Нагрузочного тестирования. Пример: Если отправить PUT несколько раз — результат будет одинаковый. Если отправить POST — создастся несколько записей.

2xx — успешные ответы: 200 OK. 201 Created. 4xx — ошибки клиента: 400 Bad Request. 401 Unauthorized. 403 Forbidden. 404 Not Found. 5xx — ошибки сервера: 500 Internal Server Error. Пример: Неверный пароль → 401. Несуществующий ресурс → 404. Ошибка сервера → 500.

Headers — это служебные данные запроса и ответа. Важные: Authorization — токен доступа. Content-Type — тип данных (application/json). Accept — какие данные ожидает клиент. Пример: Authorization: Bearer token — используется для авторизации.

Body — это данные, передаваемые между клиентом и сервером. Чаще всего используется JSON. Пример запроса: { "email": "test@test.com", "password": "123456" } Пример ответа: { "id": 1, "email": "test@test.com" }

Тестирование API включает несколько уровней: 1. Проверка статуса: Соответствует ли код ответа ожидаемому. 2. Проверка структуры: Все ли поля есть. Правильные ли типы данных. 3. Проверка логики: Корректный ответ на валидные данные. Корректные ошибки на невалидные. 4. Негативные проверки: Пустые поля. Неверные данные. Отсутствие авторизации. 5. Проверка бизнес-логики: Правильность работы сценария. Пример: POST /login: валидные данные → 200 + token неверные → 401 пустые → 400

Неверные статус-коды. Некорректный JSON. Отсутствие валидации. Лишние или отсутствующие поля. Несоответствие требованиям. Ошибки в бизнес-логике. Пример: API возвращает 200, но в теле ошибка — это дефект.

Аутентификация — это проверка личности (кто ты). Авторизация — это проверка прав (что тебе можно). Пример: Логин и пароль — аутентификация. Доступ к админке — авторизация.

Bearer Token (JWT). Basic Auth. API Key. OAuth. Пример: Authorization: Bearer token

REST — это архитектурный стиль, где ресурсы доступны по URL и используются стандартные HTTP-методы. Принципы: Ресурсно-ориентированность. Статусность (stateless). Использование HTTP методов. Пример: GET /users POST /users DELETE /users/1

Проверяет: Передачу данных. Корректность обработки. Ошибки между сервисами. Использует: Логи. Trace ID. Снифферы. Пример: Фронт → API → БД → другой сервис. Ошибка может быть в любом звене.

Postman. Swagger. Curl. DevTools (Network). Снифферы. Пример: Postman используется для отправки запросов и проверки ответов.