API как связующее звено

API как связующее звено

Введение

Мы уже знаем, что фронтенд и бэкенд — разные компоненты. Но как именно они общаются? Что позволяет React-приложению в браузере получить данные от Node.js-сервера? Ответ — API.

Понимание API — один из самых важных навыков современного тестировщика.

Что такое API

API (Application Programming Interface) — это контракт, который определяет, как системы общаются друг с другом.

Представь меню в ресторане: ты (клиент) не знаешь, как готовится блюдо — ты просто делаешь заказ по меню. Официант (API) принимает заказ и возвращает готовое блюдо. Кухня (сервер) — скрыта.

API — это "меню" сервера: список доступных операций и правила их вызова.

Веб-API: HTTP в основе

В контексте веб-разработки API чаще всего работает поверх HTTP. Есть два основных стиля:

• REST API — самый распространённый. Ресурсы адресуются URL-ами, используются HTTP-методы.
• GraphQL — клиент сам указывает, какие поля ему нужны. Один endpoint, гибкие запросы.

В этом курсе мы сосредоточимся на REST API.

Эндпоинт (Endpoint)

Эндпоинт — это конкретный URL, который принимает запросы определённого типа.

Примеры:

GET  /api/users           — получить список пользователей
GET  /api/users/42        — получить пользователя с ID 42
POST /api/users           — создать нового пользователя
PUT  /api/users/42        — обновить пользователя с ID 42
DELETE /api/users/42      — удалить пользователя с ID 42

Каждый эндпоинт — это точка входа в функциональность сервера.

Структура запроса

Любой API-запрос состоит из:

Метод + URL
GET https://api.example.com/api/products/123

Заголовки (Headers):
Authorization: Bearer eyJhbGci...
Content-Type: application/json

Тело (Body) — только для POST/PUT/PATCH:
{
  "name": "Новый товар",
  "price": 999
}

Структура ответа

Ответ сервера состоит из:

Статус-код: 200 OK

Заголовки (Headers):
Content-Type: application/json

Тело (Body):
{
  "id": 123,
  "name": "Ноутбук",
  "price": 49999,
  "inStock": true
}

Тело ответа обычно в формате JSON — лёгком текстовом формате для передачи данных.

Почему тестировщику нужно знать API

Тестирование через API даёт огромные преимущества:

1. Тестируешь бизнес-логику напрямую, без зависимости от состояния UI
2. Находишь баги, которые UI скрывает (например, неверная валидация на сервере)
3. Создаёшь тестовые данные быстро — одним запросом создать 10 пользователей вместо заполнения форм вручную
4. Воспроизводишь баги точно — запрос можно скопировать и передать разработчику
5. Тестируешь негативные сценарии — отправить невалидные данные, которые UI не позволяет ввести

Пример: Форма создания товара требует обязательное поле "название". Но если послать POST-запрос без этого поля напрямую в API — вернётся ли ошибка или сервер создаст товар без названия?

Типичные ошибки в понимании

• "API = только для разработчиков" — нет, тестировщики активно используют API
• "Если UI работает, API тоже работает" — неверно, UI может не использовать все возможности API
• "API всегда возвращает JSON" — нет, может быть XML, plain text, файлы и т.д.

Что мы запомним

• API — это контракт (правила общения) между системами
• В вебе API обычно работает через HTTP (REST, GraphQL)
• Эндпоинт — конкретный URL + метод, принимающий запросы
• Запрос = метод + URL + заголовки + тело
• Ответ = статус-код + заголовки + тело (обычно JSON)
• API-тестирование позволяет проверять логику независимо от UI — это мощный инструмент тестировщика