Что такое API простыми словами: как устроен, зачем нужен и что такое REST

Слово API встречается в каждой второй вакансии и в каждом третьем разговоре про интеграции. При этом внятного объяснения обычно не дают: «это интерфейс взаимодействия систем», и человек остаётся ровно там же, где был.

Попробуем по-человечески.

Аналогия, которая работает

Представьте ресторан. Вы не заходите на кухню и не берёте сковородку сами. Вы говорите официанту, что хотите, он передаёт на кухню, приносит результат.

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

Правила важнее всего. Кухня может поменять плиту, поваров и рецептуру, но если официант принимает тот же заказ и приносит то же блюдо, вас это не касается. Так же и с API: внутри сервис можно переписать целиком, а внешний интерфейс останется.

Как выглядит на практике

Самый распространённый вид, веб-API поверх HTTP. Клиент отправляет запрос по адресу, сервер отвечает данными, чаще всего в формате JSON.

Запрос: получить пользователя с идентификатором 42.

GET /api/users/42
Authorization: Bearer <токен>

Ответ:

{
  "id": 42,
  "name": "Анна",
  "created_at": "2026-03-14T10:20:00Z"
}

Всё. Никакой магии: адрес, метод, заголовки, тело ответа.

Что такое REST

REST это не технология и не библиотека, а набор соглашений о том, как строить такие адреса и что означают методы.

Главные идеи:

Ресурсы, а не действия. Адрес описывает сущность: /users, /orders/17. Не /getUser и не /createOrderNow.

Метод описывает действие. GET читает, POST создаёт, PUT заменяет, PATCH меняет часть, DELETE удаляет.

Каждый запрос самодостаточен. Сервер не помнит предыдущий, поэтому идентификация передаётся каждый раз, обычно токеном.

Коды ответов означают одно и то же везде. 200 успех, 404 не найдено, 401 не авторизован, 500 сломалось на сервере.

Из-за этих соглашений незнакомое REST API читается почти без документации: увидели /api/orders/17/items и уже понимаете, что это позиции в заказе номер семнадцать.

Чем API отличается от базы данных

Частая путаница у новичков.

База это склад с данными. API это правила выдачи со склада: что можно взять, кому, в каком количестве и с какими проверками.

Именно поэтому нельзя просто дать всем прямой доступ к базе: там нет ни проверки прав на уровне сценариев, ни бизнес-логики, ни ограничений на нагрузку. API это ещё и защитный слой.

Что кроме REST

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

gRPC. Бинарный протокол, быстрее и строже по контракту. Обычно применяется между сервисами внутри компании, а не для публичных API.

WebSocket. Двусторонняя постоянная связь, когда данные должны приходить сами: чаты, уведомления, котировки.

SOAP. Старый формат на XML, ещё встречается в банковских и государственных интеграциях.

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

Что делает API хорошим

Предсказуемость: одинаковые правила именования, одинаковый формат ошибок, одинаковая пагинация.

Явное версионирование, чтобы изменения не ломали существующих клиентов.

Понятные ошибки: рядом с кодом 400 приходит тело с описанием, какое поле не прошло проверку.

Идемпотентность там, где она нужна. Повторный запрос из-за обрыва сети не должен создавать второй заказ.

Ограничение частоты запросов, чтобы один клиент не положил сервис всем остальным.

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

Как это тестируют

Для тестировщика API это отдельная большая тема. Проверяют код ответа, структуру тела, типы полей, обязательность, поведение при некорректных данных, права доступа и реакцию на повторный запрос.

Инструменты обычные: Postman для ручной работы, любой HTTP-клиент в коде для автотестов, схемы для проверки контракта.

Отдельная категория проверок про безопасность: можно ли получить чужие данные, подставив другой идентификатор, что вернётся без токена, не утекает ли лишнее в ответе.

Что спрашивают на собеседовании

Что такое API и зачем он нужен. Чем GET отличается от POST. Что означают коды 401, 403, 404, 500. Что такое идемпотентность. Чем REST отличается от GraphQL. Как версионируют API. Что проверять в ответе кроме статуса.

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

Механику HTTP, на которой всё это стоит, разбирали отдельно в статье про протокол HTTP.

Как быстро разобраться на практике

Возьмите любой открытый API, например сервис с данными о погоде, и сделайте несколько запросов из консоли. Посмотрите, что приходит, попробуйте передать неверные параметры, посмотрите на коды ошибок.

Полчаса такой возни объясняют больше, чем длинная теория.

А проверить себя вопросами можно в Сеньорчике: блоки по API и вебу есть в треках тестирования и бэкенда, каждый вопрос с вариантами ответов и разбором, движок возвращает темы, где вы ошибаетесь. Десять минут в день в Telegram, бесплатно.