База для QA
К списку уроков
Блок 2 · Клиент-серверная архитектура

Урок 5. API, REST и SOAP

Как приложения общаются друг с другом

Темы урока

API простыми словами, REST (GET/POST/PUT/DELETE/JSON), SOAP (XML/WSDL), REST vs SOAP, OpenAPI/Swagger, GraphQL

Видео урока

Пройти тест по уроку

Конспект урока

Главное за урок

В уроке 4 разобрали HTTP — «как» приложения общаются. В уроке 5 идём выше: API — это контракт между двумя программами поверх HTTP. Понимание API меняет то, как QA описывает баги: вместо «кнопка не работает» — «POST /orders вернул 422 с body {"error": "insufficient_funds"} при балансе > 0».

Что такое API

API = Application Programming Interface — интерфейс, через который программы общаются. Как меню в ресторане: фиксированный список того, что можно «заказать» и в каком формате.

  • Программы не умеют читать мысли — им нужен чёткий контракт.
  • Без API весь интернет рассыплется: оплата, погода, карты, соцсети — всё держится на API-вызовах.
  • Сломанный API → пользователь видит «что-то пошло не так».

REST: архитектурный стиль поверх HTTP

REST = Representational State Transfer — это архитектурный стиль, не отдельный протокол. Работает поверх HTTP.

Ключевые принципы:

  • Stateless — сервер не хранит состояние между запросами; каждый запрос самодостаточен.
  • Единый интерфейс — одинаковые правила для разных ресурсов.
  • Слоистость — между клиентом и сервером могут стоять прокси, кэши, балансировщики.
  • Клиент-сервер — разделение ответственности.

Семантика: ресурсы и CRUD

В REST URL описывает ресурс (существительное), метод — глагол:

Действие HTTP-метод Пример
Create POST POST /users
Read GET GET /users/123
Update PUT/PATCH PUT /users/123
Delete DELETE DELETE /users/123

Эндпоинты всегда существительные: /users, /orders/123, /products?category=phones. Никогда /getUser или /createOrder.

JSON — стандарт ответов REST

JSON = JavaScript Object Notation — текстовый формат «ключ: значение» в фигурных скобках.

{
  "id": 123,
  "name": "Маргарита",
  "price": 590,
  "available": true
}

Тестировщик обязан:

  • читать JSON: находить поля, проверять типы, видеть вложенность;
  • проверять обязательность полей и формат значений (id, дата, email);
  • понимать, что в REST тело запроса/ответа = JSON.

SOAP: строгий протокол для корпоративных систем

SOAP = Simple Object Access Protocol — это протокол (не стиль, как REST). Использует XML и WSDL.

Что REST SOAP
Тип Архитектурный стиль Протокол
Формат JSON (обычно) XML
Контракт OpenAPI / Swagger WSDL
Где живёт 90% новых проектов Банки, страховые, госсектор
Для QA Лёгкий, гибкий Строгий, типизированный, с транзакциями

SOAP-сообщение = XML-конверт: Envelope → Header (метаданные) + Body (само сообщение).

QA должен уметь работать с обоими — оба встретятся в реальных проектах.

OpenAPI и Swagger

OpenAPI Specification (OAS) — стандарт описания REST API в YAML/JSON.
Swagger UI — веб-страница с документацией, которая строится из спецификации автоматически.

В Swagger UI смотрят:

  • Метод и путь: GET /users/{id} — какой метод и есть ли path-параметры.
  • Параметры: query (?search=), path (/{id}), header (Authorization) — какие обязательны и какого типа.
  • Responses: что возвращает при 200, 400, 404, 500.
  • Schemas — описание объектов: поля, типы, обязательность.
  • Кнопка «Try it out» — запросить прямо из браузера, без Postman.

Что обязан проверять QA в REST API

  • Позитив: правильные данные → 200/201 + корректный JSON.
  • Негатив: пустые поля, неверные типы, несуществующий ID → правильный код ошибки (400/404/422).
  • Авторизация: без токена → 401, с чужим → 403, с истёкшим → 401/403.
  • Граничные значения: ?limit=0, limit=-1, очень большие значения — должен быть 400, а не 500.
  • Контент: что POST вернул в id — нужен для следующего запроса в цепочке?

Топ багов в REST

  • 200 OK, но данные в теле некорректны или отсутствуют.
  • POST создал ресурс, но в ответе нет ID — нельзя продолжить цепочку.
  • Неверный код ответа: 500 вместо 400 на плохой ввод.
  • POST вернул 200 вместо 201 (или наоборот) — расхождение с контрактом.

GraphQL — упоминание

GraphQL — альтернатива REST: один эндпоинт, клиент сам указывает нужные поля. Нет over-fetching и under-fetching. В этом марафоне глубоко не разбираем — REST первичен, GraphQL — следующий шаг.

Инструменты QA для API

  • Браузер + DevTools → Network — самый быстрый способ увидеть запросы.
  • Postman (урок 16) — коллекции, окружения, авторизация, ассерты.
  • curl — терминальный инструмент для быстрых проверок.

Ключевые тезисы для теста

  • API — контракт между двумя программами.
  • REST — архитектурный стиль поверх HTTP; SOAP — протокол поверх HTTP.
  • В REST: URL = ресурс (существительное), метод = действие (глагол).
  • CRUD = POST / GET / PUT / DELETE — спросят на каждом собесе.
  • В REST тело запроса/ответа — обычно JSON. В SOAP — XML.
  • Статус-коды в REST те же, что в HTTP. 200 ≠ «всё ок» — проверять и тело.
  • OpenAPI/Swagger — стандарт описания REST API. Swagger UI — живая документация.
  • В Swagger смотрим: метод, путь, параметры, responses, schemas.
  • QA проверяет позитив, негатив, авторизацию, границы.

Полезные ссылки