REST API и HTTP-методы спрашивают почти на каждом собеседовании QA — это фундаментальная база, без которой не получится тестировать ни одно современное веб- или мобильное приложение. При этом объяснить своими словами, что такое API, для новичка часто сложнее, чем выучить список методов наизусть. Разберём тему так, как её объясняют на курсе: через интерфейс, контракт и понятные бытовые аналогии — от выключателя света до автомата со сладостями.
Что такое API и зачем он вообще нужен
Раньше HTML-разметка и данные жили в одном файле — это работало, пока существовал только веб. Но появились мобильные приложения, которым HTML не подходит, появились SPA с динамической подгрузкой данных, появились разные клиенты для одной и той же системы. Понадобился слой абстракции: данные хранятся отдельно в базе, представление (веб-страница, мобильный экран) — отдельно, а между ними — API. Меняется что-то в базе данных — обновление сразу видно во всех клиентах, которые к этой базе обращаются.
API — Application Programming Interface, интерфейс программирования приложений. Ключевое слово здесь — интерфейс. У программы есть пользовательский интерфейс — кнопки и экраны для человека. У бэкенда есть API — «кнопки» для других разработчиков и систем. Понять принцип помогают простые аналогии: выключатель — простой интерфейс к сложной электросети, руль и педали — интерфейс к сложному двигателю, которым не нужно управлять напрямую. Ещё одна полезная метафора — API как контракт: договор между сторонами о том, по каким правилам они обмениваются данными, как две железнодорожные станции договариваются о правилах перевозки груза по рельсам.
Наглядный пример — API ВКонтакте. Есть открытая документация, любой разработчик может использовать её в своих приложениях: например, сервисы отложенного постинга работают именно через API ВКонтакте — берут те же данные и ту же базу, но показывают их через собственный интерфейс. При этом у API есть и ограничения: например, прочитать личные сообщения любого пользователя через него нельзя — такое действие запрещено на уровне самого API.
API — Application Programming Interface, интерфейс программирования приложений. Ключевое слово здесь — интерфейс. У программы есть пользовательский интерфейс — кнопки и экраны для человека. У бэкенда есть API — «кнопки» для других разработчиков и систем. Понять принцип помогают простые аналогии: выключатель — простой интерфейс к сложной электросети, руль и педали — интерфейс к сложному двигателю, которым не нужно управлять напрямую. Ещё одна полезная метафора — API как контракт: договор между сторонами о том, по каким правилам они обмениваются данными, как две железнодорожные станции договариваются о правилах перевозки груза по рельсам.
Наглядный пример — API ВКонтакте. Есть открытая документация, любой разработчик может использовать её в своих приложениях: например, сервисы отложенного постинга работают именно через API ВКонтакте — берут те же данные и ту же базу, но показывают их через собственный интерфейс. При этом у API есть и ограничения: например, прочитать личные сообщения любого пользователя через него нельзя — такое действие запрещено на уровне самого API.
Какие бывают API
API делятся по уровню доступа. Частные, или внутренние, работают только внутри компании — например, для общения между микросервисами одной системы. Общедоступные платные предполагают оплату за использование: сервис Dadata, который отдаёт базу адресов по подписке, — типичный пример: вместо того чтобы самим собирать и постоянно обновлять базу домов и улиц, сервис просто подключает готовый API и платит фиксированную сумму в месяц за лимит запросов. Общедоступные бесплатные открыты для всех — VK, Telegram, HeadHunter. Партнёрские API работают по отдельной договорённости между конкретными компаниями, обычно в B2B-интеграциях. Отдельная категория — Web API, которые браузер сам предоставляет разработчикам: Geolocation, Audio, Video, WebSocket.
REST API: архитектурный стиль, а не протокол
REST API — не протокол и не отдельная программа, а архитектурный стиль построения API, максимально использующий возможности HTTP. Идея простая: у HTTP уже есть всё нужное — запросы, ответы, URL, заголовки, тело, статус-коды — и незачем изобретать поверх него что-то ещё. Без HTTP REST API не существует в принципе, это его фундамент.
У REST пять принципов. Client-Server — приложение разделено на клиентскую и серверную части. HTTP-based — взаимодействие идёт по протоколу HTTP. Operations in requests — все операции описываются прямо в запросе через комбинацию метода и URL. Stateless — сервер не хранит состояние клиента между запросами, каждый запрос обрабатывается как первый; это похоже на то, как хозяин телефона не знает, кто ему звонит, пока не поднимет трубку. Cacheable responses — ответы могут кэшироваться, причём GET-запросы кэшируются по умолчанию, POST иногда, а PUT и DELETE обычно нет.
У REST пять принципов. Client-Server — приложение разделено на клиентскую и серверную части. HTTP-based — взаимодействие идёт по протоколу HTTP. Operations in requests — все операции описываются прямо в запросе через комбинацию метода и URL. Stateless — сервер не хранит состояние клиента между запросами, каждый запрос обрабатывается как первый; это похоже на то, как хозяин телефона не знает, кто ему звонит, пока не поднимет трубку. Cacheable responses — ответы могут кэшироваться, причём GET-запросы кэшируются по умолчанию, POST иногда, а PUT и DELETE обычно нет.
CRUD и HTTP-методы
CRUD — аббревиатура четырёх базовых операций с данными: Create (создать), Read (прочитать), Update (обновить), Delete (удалить). Каждой соответствует свой HTTP-метод: Create — POST, Read — GET, Update — PUT, Delete — DELETE. Например, для сущности /users типичный набор маршрутов выглядит так: GET /users возвращает список всех пользователей, GET /users/12 — конкретного пользователя с id 12, POST /users создаёт нового, PUT /users/12 обновляет существующего, DELETE /users/12 удаляет его. Важное правило для тестировщика: если два запроса с одинаковой структурой делают разные вещи — это баг в дизайне API. Технически можно реализовать все операции через один POST, но так не делают крупные публичные API вроде VK или HeadHunter: другому разработчику будет неудобно и непонятно с таким API работать, а хорошее API проектируют так, чтобы им хотелось пользоваться.
Endpoint — ручка, и Swagger как документация
Endpoint, или на сленге тестировщиков и разработчиков «ручка», — это конечная точка API, конкретный адрес для конкретного действия. Хорошая метафора — компания с несколькими сотрудниками: по юридическим вопросам обращаются к одному специалисту, по вопросам дизайна — к другому, у каждого своя «точка входа». Или автомат со сладостями: дёрнул за красную ручку — получил один результат, за синюю — другой. У каждой ручки своё чётко определённое назначение, и в этом суть эндпоинта.
У крупных систем — сотни эндпоинтов, и чтобы внешние разработчики и новые сотрудники могли в них ориентироваться, нужна стандартная документация. Здесь на сцену выходит OpenAPI — самый популярный формат описания REST API, который раньше назывался Swagger Specification. А Swagger — инструмент, который визуализирует OpenAPI-описание и превращает его в интерактивную документацию: можно посмотреть все эндпоинты, отправить тестовый запрос прямо из браузера и увидеть ответ. Документацию либо пишут вручную в формате YAML, либо генерируют автоматически из аннотаций в коде — второй способ быстрее и всегда актуален, но требует правильно оформленного кода. Пример из открытого доступа — документация HeadHunter на dev.hh.ru: базовый URL, список эндпоинтов вроде /vacancies и /auth/token, форматы запросов и ответов, примеры ошибок с кодами 400, 401, 403.
Стандартный рабочий флоу тестировщика: сначала изучить эндпоинты и структуру данных через Swagger, а затем перенести нужные запросы в Postman — инструмент, где их можно сохранять, объединять в коллекции, переменные и автотесты, чего в самом Swagger нет. Тестировщики документацию API обычно не пишут сами — это задача технического писателя, — но активно её тестируют: проверяют, соответствует ли реальное поведение API описанному, и репортят несоответствия.
REST, CRUD, статус-коды и Swagger складываются в целостную картину только тогда, когда прогоняешь их руками на реальном API, а не запоминаешь по табличке. На курсе «Инженер по ручному тестированию» это отдельный практический блок Спринта 7: ученики проходят сценарий от создания сущности через Swagger до полноценного тестирования в Postman на учебном API школы, и разбирают вопросы с ментором, а не только с документацией.
-------
У крупных систем — сотни эндпоинтов, и чтобы внешние разработчики и новые сотрудники могли в них ориентироваться, нужна стандартная документация. Здесь на сцену выходит OpenAPI — самый популярный формат описания REST API, который раньше назывался Swagger Specification. А Swagger — инструмент, который визуализирует OpenAPI-описание и превращает его в интерактивную документацию: можно посмотреть все эндпоинты, отправить тестовый запрос прямо из браузера и увидеть ответ. Документацию либо пишут вручную в формате YAML, либо генерируют автоматически из аннотаций в коде — второй способ быстрее и всегда актуален, но требует правильно оформленного кода. Пример из открытого доступа — документация HeadHunter на dev.hh.ru: базовый URL, список эндпоинтов вроде /vacancies и /auth/token, форматы запросов и ответов, примеры ошибок с кодами 400, 401, 403.
Стандартный рабочий флоу тестировщика: сначала изучить эндпоинты и структуру данных через Swagger, а затем перенести нужные запросы в Postman — инструмент, где их можно сохранять, объединять в коллекции, переменные и автотесты, чего в самом Swagger нет. Тестировщики документацию API обычно не пишут сами — это задача технического писателя, — но активно её тестируют: проверяют, соответствует ли реальное поведение API описанному, и репортят несоответствия.
REST, CRUD, статус-коды и Swagger складываются в целостную картину только тогда, когда прогоняешь их руками на реальном API, а не запоминаешь по табличке. На курсе «Инженер по ручному тестированию» это отдельный практический блок Спринта 7: ученики проходят сценарий от создания сущности через Swagger до полноценного тестирования в Postman на учебном API школы, и разбирают вопросы с ментором, а не только с документацией.
-------
Полезные ссылки школы
Сайт Quality Academy:
/main
Telegram-канал:
https://t.me/quality_academy
YouTube-канал:
https://www.youtube.com/@quality_academy
ВКонтакте:
https://vk.com/quality_academy
Канал отзывов учеников (58+ отзывов):
https://t.me/quality_academy_reviews
Задать вопрос менеджеру:
https://t.me/quality_academy_bot
Тест «Подойдёт ли вам тестирование»:
https://quiz.quality-academy.ru
5000+ вопросов с собесов тестировщика — бот-тренажёр:
https://t.me/quality_academy_interview_bot
3 практические задачи и дорожная карта:
https://t.me/quality_academy_tasks_bot
Бесплатные тренажёры — SQL Arena, Playwright Arena, Python Arena:
SQL Arena · Playwright Arena · Python Arena
/main
Telegram-канал:
https://t.me/quality_academy
YouTube-канал:
https://www.youtube.com/@quality_academy
ВКонтакте:
https://vk.com/quality_academy
Канал отзывов учеников (58+ отзывов):
https://t.me/quality_academy_reviews
Задать вопрос менеджеру:
https://t.me/quality_academy_bot
Тест «Подойдёт ли вам тестирование»:
https://quiz.quality-academy.ru
5000+ вопросов с собесов тестировщика — бот-тренажёр:
https://t.me/quality_academy_interview_bot
3 практические задачи и дорожная карта:
https://t.me/quality_academy_tasks_bot
Бесплатные тренажёры — SQL Arena, Playwright Arena, Python Arena:
SQL Arena · Playwright Arena · Python Arena