Что со стороны клиента отправлял на Backend

Отличный вопрос. Со стороны клиента на Backend отправляется всё, что необходимо для корректной работы веб-приложения или API. Можно разделить эти данные на несколько ключевых категорий.

Основные категории данных, отправляемых клиентом

Клиент (браузер, мобильное приложение, другой сервис) формирует и отправляет HTTP/HTTPS запрос, который состоит из нескольких частей.

1. Метаданные запроса (HTTP Заголовки - Headers)

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

• User-Agent: Идентифицирует тип клиента (браузер, ОС, версия). Важен для анализа и адаптивного рендеринга.
• Authorization / Cookie: Содержат учетные данные (токен, сессию) для аутентификации и авторизации пользователя.
• Content-Type: Указывает тип передаваемых данных (например, application/json, multipart/form-data). Backend использует это, чтобы правильно распарсить тело запроса.
• Accept: Сообщает серверу, какие типы данных (JSON, XML) клиент готов принять в ответ.
• Host, Origin, Referer: Используются для безопасности (CORS), логирования и аналитики.

2. Параметры запроса (Query Parameters / URL Params)

Данные, передаваемые прямо в URL после знака ?. Часто используются для фильтрации, пагинации и GET-запросов. Пример запроса к API:

GET /api/v1/products?category=electronics&sort=price&page=2&limit=20

Здесь на Backend отправятся параметры: category=electronics, sort=price, page=2, limit=20.

3. Данные маршрута (Path Parameters / Route Params)

Часть самого пути URL, которая динамически подставляется. Обычно идентифицирует конкретный ресурс.

GET /api/v1/users/12345/profile

Здесь 12345 — это path parameter, идентификатор пользователя, который Backend извлекает из маршрута.

4. Тело запроса (Request Body)

Самый распространенный способ передачи структурированных данных для операций создания (POST), обновления (PUT/PATCH). Формат определяется заголовком Content-Type.

• JSON (application/json): Самый популярный формат для REST API.

{
  "username": "john_doe",
  "email": "john@example.com",
  "password": "securePass123"
}

• Данные формы (application/x-www-form-urlencoded): Как отправляется HTML-форма. Данные кодируются в виде пар key=value, соединенных &.
• Мультипарт-данные (multipart/form-data): Используются для отправки файлов вместе с текстовыми полями (загрузка аватара, формы с вложениями).

5. Данные для нестандартных методов

• GraphQL-запросы: В теле запроса отправляется строка с GraphQL-запросом (query) и переменными (variables).

{
  "query": "query GetUser($id: ID!) { user(id: $id) { name email } }",
  "variables": { "id": "12345" }
}

Взгляд QA Engineer: Что важно проверять?

Как инженер по качеству, я не просто знаю, что отправляется, но и тщательно проверяю корректность, безопасность и обработку граничных случаев этих данных.

1. Валидация на стороне клиента — НЕ гарантия! Первое и главное правило: всегда дублирую проверки, эмулируя запросы напрямую к API (через Postman, Swagger, скрипты), минуя UI. UI-валидацию можно обойти.
2. Тестирование граничных значений и некорректных данных:

    *   Что будет, если в `username` отправить строку в 10 000 символов?
    *   Что если в числовое поле `price` отправить отрицательное число, ноль, строку `"десять"`?
    *   Отправка пустого тела (`{}`) или `null` в обязательные поля.
    *   Проверка типов данных: отправить массив туда, где ожидается строка.

1. Тестирование безопасности (Security Testing):

    *   **SQL-инъекции**: Попытка отправить в поле для поиска `' OR '1'='1`.
    *   **XSS**: Попытка вставить скрипт в текстовые поля (`<script>alert('xss')</script>`).
    *   **Манипуляция данными**: Изменение `userId` в теле запроса или параметрах пути, чтобы попытаться получить доступ к чужим данным (Insecure Direct Object Reference - IDOR).
    *   **Повторная отправка (Replay Attack)**: Перехват и повторение авторизованного запроса.

1. Проверка заголовков:

    *   Что происходит, если не отправить обязательный `Authorization`?
    *   Как Backend реагирует на неожиданный `Content-Type`?
    *   Тестирование CORS: отправка запроса с другого `Origin`.

1. Работа с файлами:

    *   Загрузка файлов запрещенных типов (`.exe`, `.php`).
    *   Загрузка файлов-«пустышек» (нулевого размера).
    *   Загрузка файлов огромного размера (проверка лимитов).

1. Анализ сетевого трафика: Использую инструменты вроде Chrome DevTools (вкладка Network) или Fiddler/Charles Proxy, чтобы:

    *   Убедиться, что клиент отправляет именно те данные, которые я ввожу в интерфейсе.
    *   Перехватывать и модифицировать запросы «на лету» для тестирования негативных сценариев.
    *   Проверять, не «утекают» ли в запросах чувствительные данные (пароли в открытом виде, лишние токены).

Вывод для QA: Понимание структуры HTTP-запроса — фундамент для тестирования API, который является основой большинства современных приложений. Мы должны проверять не только «счастливый путь», когда все данные корректны, но и думать, как злоумышленник или невнимательный пользователь может сломать эту коммуникацию, и как Backend должен адекватно на это реагировать (возвращая понятные 400 Bad Request, 401 Unauthorized или 422 Unprocessable Entity ошибки, а не падая с 500 Internal Server Error).