Содержание

• Введение

• Что такое REST

• История появления REST

• Основные принципы REST

• Что такое RESTful API

• Методы HTTP в REST

• Идемпотентность HTTP-методов

• HATEOAS — последний уровень зрелости REST

• Коды ответов HTTP REST в тестировании

• Инструменты для работы с REST

• Выводы

Введение

Практически каждый современный веб-сервис, мобильное приложение или микросервис использует API для обмена данными между компонентами системы. В большинстве случаев речь идет именно о REST API.

Поэтому знание REST сегодня является одним из базовых навыков QA Engineer. Независимо от того, занимается ли специалист ручным тестированием или автоматизацией, понимание принципов REST помогает эффективнее анализировать работу системы, находить дефекты и писать качественные тесты.

В данной статье разберем основные принципы REST, поговорим о RESTful API, HTTP-методах, статус-кодах, идемпотентности и особенностях тестирования API.

Что такое REST

REST (Representational State Transfer) — архитектурный стиль взаимодействия компонентов распределённой системы.

Термин был предложен Роем Филдингом в 2000 году в его докторской диссертации.

Важно понимать, что REST не является:

• протоколом;

• языком программирования;

• библиотекой;

• фреймворком.

REST представляет собой набор архитектурных ограничений и рекомендаций по построению API.

Важно: REST не требует использования JSON. API может передавать данные в различных форматах, например XML, YAML или даже обычном тексте. Однако на практике именно JSON стал фактическим стандартом для большинства современных REST API благодаря своей простоте и удобству обработки.

Главная идея заключается в том, что каждая сущность системы рассматривается как ресурс.

Примеры ресурсов:

• пользователь;

• заказ;

• товар;

• комментарий;

• платеж.

Доступ к ресурсам осуществляется через HTTP.

Например:

GET /users/15

Получение пользователя.

DELETE /users/15

Удаление пользователя.

PUT /users/15

Обновление пользователя.

История появления REST

До широкого распространения REST многие компании использовали SOAP (Simple Object Access Protocol) — протокол обмена структурированными сообщениями в распределённых системах.

SOAP предоставлял большие возможности, однако имел ряд недостатков:

• громоздкие XML-сообщения;

• сложную спецификацию;

• высокие накладные расходы;

• сложность поддержки.

Рой Филдинг предложил использовать уже существующие возможности HTTP (HyperText Transfer Protocol — протокол прикладного уровня для передачи данных в веб-системах) и строить взаимодействие вокруг ресурсов.

Подход оказался значительно проще и эффективнее, благодаря чему REST постепенно стал стандартом де-факто для веб-разработки.

Сегодня REST применяется практически повсеместно:

• веб-приложения;

• мобильные приложения;

• микросервисная архитектура;

• облачные платформы;

• публичные API.

Основные принципы REST

REST базируется на нескольких обязательных ограничениях.

Клиент—серверная архитектура (Client-Server)

Клиент и сервер разделены между собой.

Клиент отвечает за пользовательский интерфейс.

Сервер отвечает за хранение и обработку данных.

Отсутствие состояния (Stateless)

Каждый запрос должен содержать всю необходимую информацию.

Сервер не хранит состояние клиента между запросами.

Например:

GET /profile
Authorization: Bearer token

Токен передается в каждом запросе.

Это позволяет легко масштабировать систему.

Кэшируемость (Cacheable)

Ответы сервера могут кэшироваться.

Например:

Cache-Control: max-age=3600

Клиент может использовать сохраненный ответ в течение часа без обращения к серверу.

Единый интерфейс (Uniform Interface)

Все ресурсы используют единый интерфейс взаимодействия.

Например:

GET /users
GET /orders
GET /products

Независимо от ресурса используются одинаковые HTTP-механизмы.

Многоуровневая система (Layered System)

Клиент может взаимодействовать не напрямую с сервером, а через промежуточные слои:

• балансировщики нагрузки;

• прокси;

• API Gateway;

• CDN.

Код по требованию (Code-on-Demand) (необязательное ограничение)

Сервер может передавать клиенту исполняемый код для расширения его функциональности.

Наиболее распространённый пример — передача JavaScript-кода веб-браузеру.

Благодаря этому клиент может получать новую функциональность без обновления приложения.

Однако в REST API данный принцип используется редко, поэтому считается опциональным ограничением REST.

Что такое RESTful API

RESTful API — это API, которое соблюдает принципы REST.

Не любой HTTP API является RESTful.

Плохой пример:

POST /createUser
POST /deleteUser
POST /getUser

Такой подход напоминает удалённый вызов процедур (RPC).

RESTful вариант выглядит следующим образом:

POST /users
GET /users/1
PUT /users/1
DELETE /users/1

В этом случае действие определяется HTTP-методом, а URL описывает ресурс.

Методы HTTP в REST

REST активно использует возможности протокола HTTP.

GET

Получение данных.

GET /users/1

POST

Создание нового ресурса.

POST /users

PUT

Полное обновление ресурса.

PUT /users/1

PATCH

Частичное обновление ресурса.

PATCH /users/1

DELETE

Удаление ресурса.

DELETE /users/1

Идемпотентность HTTP-методов

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

Например:

DELETE /users/15

Первый запрос удаляет пользователя (200 OK или 204 No Content). Повторный запрос к тому же URL вернёт 404 Not Found. Состояние системы на сервере (пользователя 15 нет) после первого и второго запросов одинаково. Именно это и означает идемпотентность: повторные запросы не меняют состояние сервера, даже если HTTP-код ответа отличается.

Важно для QA: идемпотентность не гарантирует одинаковый ответ — она гарантирует одинаковое состояние системы.

Таблица идемпотентности

Почему это важно для QA

Во время тестирования необходимо проверять:

• повторные запросы;

• защиту от дублей;

• корректную работу Retry-механизмов;

• обработку сетевых ошибок.

Особенно важно это для:

• платежей;

• переводов;

• заказов;

• бронирований.

HATEOAS — последний уровень зрелости REST

HATEOAS (Hypermedia As The Engine Of Application State) считается одним из официальных принципов REST.

Суть заключается в том, что сервер сам сообщает клиенту доступные действия через ссылки.

Пример ответа:

{
  "id": 15,
  "name": "John",
  "_links": {
    "self": {
      "href": "/users/15"
    },
    "orders": {
      "href": "/users/15/orders"
    },
    "delete": {
      "href": "/users/15"
    }
  }
}

Клиент получает не только данные, но и информацию о дальнейших действиях.

Модель зрелости Richardson

Большинство современных API находятся на Level 2.

Полноценный HATEOAS в классическом понимании встречается реже, чем Level 2, но его элементы (например, поле self или ссылки на связанные ресурсы) используются во многих современных API — JSON:API, HAL. GraphQL использует иной подход к взаимодействию клиента и сервера и обычно не относится к HATEOAS.

Коды ответов HTTP

REST активно использует стандартные HTTP Status Codes.

Успешные ответы

Ошибки клиента

Ошибки сервера

REST в тестировании

Для QA-инженера REST API является одним из основных объектов тестирования.

Наиболее распространённые проверки:

Проверка статус-кодов

Необходимо убедиться, что сервер возвращает корректный код ответа.

Например:

• создание ресурса — 201;

• удаление — 204;

• отсутствующий объект — 404.

Проверка структуры ответа

Тестировщик проверяет:

• обязательные поля;

• типы данных;

• вложенные объекты;

• соответствие документации.

Проверка бизнес-логики

Например:

1. Создать пользователя.

2. Получить пользователя.

3. Проверить сохранённые данные.

Проверка безопасности

Следует тестировать:

• авторизацию;

• роли пользователей;

• доступ к чужим данным;

• работу токенов.

Чек-лист REST API

• корректность HTTP-методов;

• корректность статус-кодов;

• валидация входных данных;

• обработка пустых значений;

• обработка специальных символов;

• проверка авторизации;

• проверка ролей;

• проверка пагинации;

• проверка сортировки;

• проверка фильтрации;

• проверка версионирования API (/v1/ vs /v2/);

• проверка производительности;

• проверка идемпотентности.

Инструменты для работы с REST

Postman

Самый популярный инструмент тестирования API.

Возможности:

• отправка запросов;

• коллекции;

• переменные окружения;

• автотесты;

• Collection Runner.

Swagger / OpenAPI

Позволяет документировать API и быстро изучать доступные эндпоинты.

Insomnia

Упрощённая альтернатива Postman.

curl

Консольный инструмент для отправки HTTP-запросов.

Пример:

curl -X GET https://api.example.com/users/1

Выводы

REST является самым популярным архитектурным стилем построения API в современных системах.

Для QA Engineer понимание REST необходимо по нескольким причинам:

• большинство современных проектов используют REST API;

• REST регулярно встречается на собеседованиях;

• знание HTTP помогает быстрее находить дефекты;

• API-тестирование является важной частью работы тестировщика.

Понимание принципов REST, HTTP-методов, статус-кодов, идемпотентности и HATEOAS позволяет QA-инженеру глубже анализировать систему, писать более качественные тесты и эффективнее взаимодействовать с разработчиками.