Шпаргалка по API для QA. Часть 2: HTTP и данные
QA❤️4LifeШпаргалка по API для QA. Часть 2: HTTP и данные
Структура HTTP-запроса и ответа, методы (GET, POST, PUT, PATCH, DELETE), CRUD-операции, форматы данных JSON и XML, коды состояния HTTP.
Канал: QA❤️4Life
Автор: Евгений Гусинец
Часть 2: Анатомия HTTP-взаимодействия
Эта часть посвящена строительным блокам любого API-тестирования. Мы разберем, из чего состоят запросы и ответы, какие бывают методы и как они влияют на операции с данными.
2.1. Структура HTTP-запроса (Request)
Вопросы с собеседований:
Опишите структуру HTTP-запроса.
Что такое «методы передачи данных»?
Какие методы передачи данных вы знаете?
HTTP-запрос — это сообщение, которое клиент отправляет серверу, чтобы запросить какое-либо действие. Он состоит из трех (иногда четырех) основных частей:
Стартовая строка (Start Line): Самая первая строка, задающая суть запроса.
Метод (Method): Команда, которая говорит серверу, что нужно сделать с ресурсом (например, GET, POST). Это и есть "методы передачи данных".
URI (Uniform Resource Identifier): Путь к ресурсу, над которым нужно совершить действие (например, /users/123).
Версия HTTP: Версия протокола, обычно HTTP/1.1 или HTTP/2.
Пример: GET /users/123 HTTP/1.1
Заголовки (Headers): Это строки с дополнительной информацией и метаданными, которые помогают серверу правильно обработать запрос. Они идут в формате Ключ: Значение.
Host: Обязательный заголовок. Указывает доменное имя сервера (например, api.example.com).
Content-Type: Говорит серверу, в каком формате данные отправлены в теле запроса (например, application/json). Критически важен для POST/PUT/PATCH запросов.
Authorization: Содержит данные для аутентификации (например, Bearer eyJhbGciOiJIUzI1Ni...).
Accept: Говорит серверу, в каком формате клиент хочет получить ответ (например, application/xml).
User-Agent: Информация о клиенте, который отправил запрос (например, PostmanRuntime/7.29.2).
Cookie: Содержит куки, ранее установленные сервером.
Пустая строка: Обязательная пустая строка, которая отделяет заголовки от тела запроса.
Тело (Body / Payload): Необязательная часть. Содержит данные, которые клиент отправляет на сервер. Тело используется в методах POST, PUT, PATCH. Для GET и DELETE запросов тело обычно не используется.
Пример (в формате JSON): {"name": "Ivan", "lastName": "Ivanov"}
Пример полного HTTP-запроса:
POST /users HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer mysecrettoken
{
"name": "Ivan",
"lastName": "Ivanov"
}
2.2. HTTP-методы и CRUD-операции
Вопросы с собеседований:
Что такое CRUD-операции?
Чем отличается GET от POST-запроса?
Что такое GET-запрос, что он делает?
Чем отличается PUT от PATCH?
Есть список пользователей, и его необходимо отредактировать. Какие методы передачи данных вы бы посоветовали использовать для проверки этого тест-кейса?
Какую последовательность операций нужно создать для того, чтобы методы API сработали? Для ситуации, когда есть список пользователей, в который необходимо добавить пользователя по имени и фамилии.
CRUD — это акроним, описывающий четыре базовые функции для работы с данными (на примере сущности "пользователь"):
Create (Создать) — Создать нового пользователя.
Read (Прочитать) — Получить информацию о пользователе.
Update (Обновить) — Изменить существующего пользователя.
Delete (Удалить) — Удалить пользователя.
В REST API эти операции напрямую сопоставляются с HTTP-методами:
Ключевые отличия методов:
GET vs POST:
Цель: GET — только для получения данных. POST — для создания нового ресурса или отправки данных на обработку.
Передача параметров: GET передает параметры в строке URL (например, /users?status=active). POST передает данные в теле (Body) запроса.
Безопасность: GET-запрос считается "безопасным" (не в смысле шифрования, а в смысле того, что он не должен изменять данные на сервере). POST — небезопасный, так как он создает или изменяет данные.
Кеширование: GET-запросы могут кешироваться браузером, POST — нет.
Видимость данных: Параметры GET-запроса видны в URL, в истории браузера и логах сервера. Данные POST скрыты в теле запроса (но видны при перехвате трафика, если не используется HTTPS).
Ограничения: Длина URL ограничена, поэтому в GET нельзя передать очень много данных. У тела POST-запроса таких ограничений практически нет.
PUT vs PATCH:
Оба метода используются для обновления ресурса. Разница в подходе. Представим, что у нас есть пользователь { "name": "Anna", "email": "anna@test.com" }.
PUT (Полная замена): Если вы хотите изменить только имя, вы должны отправить весь объект целиком, включая неизмененный email:
PUT /users/123
{ "name": "Anastasia", "email": "anna@test.com" }
Если вы отправите только { "name": "Anastasia" }, то поле email будет стерто (станет null), так как PUT полностью заменяет ресурс.
PATCH (Частичное обновление): Вы отправляете только те поля, которые хотите изменить:
PATCH /users/123
{ "name": "Anastasia" }
При этом поле email останется без изменений.
Практические кейсы с собеседований :
Отредактировать список пользователей: Для редактирования конкретного пользователя из списка идеально подходят PUT или PATCH. Если нужно отредактировать сразу нескольких пользователей одним запросом (например, поменять статус у группы), часто используют POST-запрос на специальный эндпоинт (например, POST /users/batch-update).
Последовательность для добавления пользователя:
Формирование запроса: Создать POST-запрос на эндпоинт, отвечающий за создание пользователей (например, /users).
Заголовки: Указать заголовок Content-Type: application/json.
Тело запроса: В тело поместить JSON-объект с данными нового пользователя: { "name": "Ivan", "lastName": "Ivanov" }.
Авторизация (если требуется): Добавить заголовок Authorization с валидным токеном.
Отправка и проверка: Отправить запрос и проверить, что:
Сервер вернул успешный код (обычно 201 Created).
В теле ответа содержится информация о созданном пользователе, включая его уникальный id.
2.3. Структура HTTP-ответа (Response)
HTTP-ответ — это сообщение, которое сервер отправляет клиенту в ответ на его запрос. Он тоже имеет четкую структуру:
Строка состояния (Status Line):
Версия HTTP: HTTP/1.1.
Код состояния (Status Code): Трехзначное число, показывающее результат обработки запроса (например, 200).
Сообщение состояния (Reason Phrase): Текстовое описание кода (например, OK).
Пример: HTTP/1.1 200 OK
Заголовки (Headers): Аналогичны заголовкам запроса, но несут информацию от сервера.
Content-Type: В каком формате сервер прислал данные в теле ответа (например, application/json).
Content-Length: Размер тела ответа в байтах.
Set-Cookie: Команда для браузера установить куки.
Server: Информация о веб-сервере (например, nginx).
Date: Дата и время генерации ответа.
Пустая строка.
Тело (Body): Данные, которые сервер отправил клиенту. Это может быть HTML-страница, JSON-объект, XML, изображение и т.д.Часть 3: Данные и Статусы — Язык общения API
Эта часть посвящена тому, что именно передается в теле запросов и ответов, и как сервер сообщает клиенту о результатах своей работы с помощью кодов состояния.
3.1. Форматы данных: JSON и XML
Вопросы с собеседований:
Что такое JSON?
Что такое XML?
Чем отличается JSON от XML?
Можно ли в REST-запросе выбрать XML?
JSON (JavaScript Object Notation)
Что это? Это текстовый формат обмена данными, основанный на синтаксисе объектов JavaScript. Он легко читается как людьми, так и машинами, и сегодня является стандартом де-факто для большинства REST API.
Ключевые особенности и синтаксис:
Пары "ключ-значение": Данные представлены в виде пар, где ключ — это строка в двойных кавычках, а значение — строка, число, булево значение (true/false), массив или другой объект.
Объекты: Заключаются в фигурные скобки {}. Представляют собой набор пар "ключ-значение".
Массивы: Заключаются в квадратные скобки []. Представляют собой упорядоченный список значений.
Пример JSON:
{
"user": {
"id": 123,
"name": "Alex",
"isAdmin": true,
"courses": [
"API Testing",
"Java for QA"
],
"address": null
}
}
XML (eXtensible Markup Language — Расширяемый язык разметки)
Что это? Это язык разметки, который определяет набор правил для кодирования документов в формате, который является одновременно человеко- и машиночитаемым. Он был популярен до широкого распространения JSON, особенно в SOAP API.
Ключевые особенности и синтаксис:
Теги: Данные заключаются в открывающие (<tag>) и закрывающие (</tag>) теги.
Иерархия: Имеет строгую древовидную структуру.
Атрибуты: Теги могут иметь атрибуты (<user id="123">).
Многословность: XML обычно более громоздкий по сравнению с JSON.
Тот же пример в XML:<?xml version="1.0" encoding="UTF-8" ?>
<user id="123">
<name>Alex</name>
<isAdmin>true</isAdmin>
<courses>
<course>API Testing</course>
<course>Java for QA</course>
</courses>
<address/>
</user>
JSON vs XML — Ключевые отличия:
Можно ли в REST использовать XML?
Да, абсолютно. REST — это архитектурный стиль, он не предписывает конкретный формат данных. Клиент и сервер могут "договориться" общаться с помощью XML. Клиент отправляет заголовок Accept: application/xml, и если сервер поддерживает этот формат, он вернет ответ в XML. На практике сегодня это встречается редко, и JSON является доминирующим форматом.
3.2. Коды состояния HTTP — Результат операции
Вопросы с собеседований:
Какие коды ошибок бывают?
Чем отличаются 401, 403 и 404?
Что такое 500-я ошибка?
Что такое 404? Что значит сервер Not Found?
Что такое ошибка 403?
Что такое ошибка 401?
Коды состояния — это универсальный способ для сервера сообщить клиенту о результате его запроса. Они делятся на 5 классов.
Классы кодов состояния:
1xx (Informational): Запрос принят, обработка продолжается. Встречаются редко.
2xx (Success): Запрос был успешно принят, понят и обработан.
200 OK: Стандартный ответ для успешных GET, PUT, PATCH.
201 Created: Ресурс был успешно создан в результате POST-запроса.
204 No Content: Запрос успешен, но в теле ответа нет данных (например, после успешного DELETE-запроса).
3xx (Redirection): Для выполнения запроса нужно предпринять дальнейшие действия (обычно перейти по другому URL).
4xx (Client Error): Ошибка на стороне клиента. Клиент отправил что-то не так.
5xx (Server Error): Ошибка на стороне сервера. С запросом клиента все в порядке, но сервер не смог его обработать из-за внутренних проблем.
Разбор популярных кодов ошибок:
404 Not Found (Не найдено)
Что значит: Сервер не смог найти ресурс по указанному URI. Это одна из самых частых ошибок.
Причины:
Опечатка в URL (эндпоинте).
Вы пытаетесь получить доступ к объекту, который был удален (например, GET /users/999, а пользователя с таким ID не существует).
Что значит "сервер Not Found"? Это неверная формулировка. Ошибка 404 означает, что сервер-то найден и работает, но он не может найти конкретный ресурс (страницу, файл, объект), который вы у него запросили.
401 Unauthorized (Не авторизован)
Что значит: Для доступа к ресурсу требуется аутентификация, но она либо не была предоставлена, либо была неверной. Сервер говорит: "Я не знаю, кто ты. Представься!".
Причины:
Вы не передали токен авторизации или API-ключ.
Вы передали неверный, просроченный или отозванный токен.
Аналогия: Попытка войти в ночной клуб без билета. Вас просто не пустят на входе.
403 Forbidden (Запрещено)
Что значит: Сервер понял ваш запрос и знает, кто вы (аутентификация пройдена), но у вас недостаточно прав для выполнения этого действия. Сервер говорит: "Я знаю, кто ты, но именно тебе сюда нельзя".
Причины:
Обычный пользователь пытается получить доступ к панели администратора.
Вы пытаетесь отредактировать чужой профиль, не имея на это прав.
Аналогия: Вы вошли в клуб по билету (401 пройдена), но пытаетесь пройти в VIP-зону, на которую у вас нет браслета. Охрана вас не пустит.
Ключевое отличие 401 vs 403:
401: Проблема с аутентификацией (КТО ТЫ?).
403: Проблема с авторизацией (ЧТО ТЕБЕ МОЖНО?).
500 Internal Server Error (Внутренняя ошибка сервера)
Что значит: Это общая ошибка, которая говорит о том, что на сервере произошло что-то непредвиденное, и он не смог выполнить корректный запрос. С вашим запросом, скорее всего, все в порядке.
Причины:
Баг в коде бэкенда (например, необработанное исключение).
Сервер не может подключиться к базе данных.
Закончилась память или место на диске.
Некорректная конфигурация сервера.
Что делать QA? Это всегда баг на стороне бэкенда. Нужно смотреть логи сервера, чтобы найти точную причину, и заводить баг-репорт для разработчиков.
Канал: QA❤️4Life
Автор: Евгений Гусинец