Какие знаешь форматы запроса?

Форматы запросов в веб-разработке и тестировании

Как QA Engineer, я рассматриваю форматы запросов с двух ключевых сторон: форматы передачи данных между клиентом и сервером (payload) и форматы самих HTTP запросов (методы, заголовки, структура). Знание этих форматов критически важно для построения корректных тестов API, понимания спецификации и анализа ошибок.

Основные форматы передачи данных (Payload)

При отправке запросов (особенно POST, PUT, PATCH) данные передаются в теле запроса в различных форматах, которые определяются заголовком Content-Type.

• application/json Наиболее распространенный формат для REST API. Данные представляются в виде текста в структуре JSON (JavaScript Object Notation).

  {
    "userId": 12345,
    "title": "Пример запроса",
    "completed": false
  }
  

  При тестировании необходимо проверять валидность JSON (синтаксис, типы данных), соответствие схеме (например, JSON Schema), а также обработку некорректного JSON сервером.

• application/xml Используется в некоторых SOAP API и legacy системах. Данные структурируются с помощью XML тегов.

  <user>
    <id>12345</id>
    <name>Пример</name>
  </user>
  

  Тестирование требует проверки корректности XML (валидность против XSD схемы, escaping специальных символов).

• multipart/form-data Ключевой формат для отправки файлов вместе с текстовыми данными. Используется в формах загрузки файлов. Каждая часть (part) имеет свой Content-Type. При тестировании важно проверять границы (boundaries), корректность передачи бинарных данных и ограничения на размер файлов.

• application/x-www-form-urlencoded Старый, но еще применяемый формат для отправки простых данных из HTML форм. Данные кодируются в строку вида key1=value1&key2=value2. Тестирование включает проверку правильного кодирования специальных символов (например, пробелов как %20).

• text/plain, application/octet-stream Специализированные форматы: первый для простого текста, второй для произвольных бинарных данных (например, загрузка файла без метаинформации).

Формат и компоненты HTTP запроса

Сам HTTP запрос имеет строго определенную текстовую структуру, которую QA должен понимать для анализа логов и написания тестов (например, через curl или вручную).

Пример базового HTTP POST запроса в формате RAW:

POST /api/v1/todos HTTP/1.1
Host: example.com
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Content-Length: 45

{"title":"Test task","completed":false}

Компоненты формата запроса:

• Метод (HTTP Method): GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS. Определяет действие над ресурсом.
• URL (Путь и параметры): Путь к ресурсу (/api/v1/todos) и возможные query parameters (?status=active&limit=10).
• HTTP Версия: обычно HTTP/1.1 или HTTP/2.
• Заголовки (Headers): Ключевые метаданные запроса. Помимо Content-Type, важны:
  • Authorization (токены, Basic Auth)
  • Accept (формат ожидаемого ответа, например Accept: application/json)
  • User-Agent, Cache-Control, Cookie
• Тело запроса (Body): Присутствует для методов, отправляющих данные. Формат тела соответствует Content-Type.

Практическое применение в QA

Для эффективного тестирования API я активно использую эти знания:

1. Создание тестовых запросов: В инструментах (Postman, REST Assured, ручные curl) я явно задаю правильный Content-Type и формат тела.
2. Анализ ошибок: Если сервер возвращает 400 Bad Request или 415 Unsupported Media Type, я первым делом проверяю соответствие формата запроса ожиданиям API (спецификации Swagger/OpenAPI).
3. Тестирование граничных условий: Например, отправка JSON с лишними пробелами, отправка XML вместо JSON, нарушение структуры multipart/form-data.
4. Проверка безопасности: Попытка отправки запросов с неожиданными форматами (например, application/javascript) для оценки устойчивости сервера.

Таким образом, глубокое понимание форматов запросов позволяет QA Engineer не только выполнять базовые проверки, но и проводить глубокое тестирование на корректность, безопасность и соответствие стандартам, что напрямую влияет на качество и надежность продукта.