Справочник

API REST: что это простыми словами

26 сентября 2026 · 15 минут чтения

Проверка фактов

Юлия Найпак

Методист по автоматизации. Сверяет паспорт инструмента с документацией вендора.

Автор Р

Редакция

Коллектив авторов, редакторов и иллюстраторов статей на сайте блога онлайн-университета «Зерокодер». Пишем…

Черновик готовит редакция с помощью ИИ. За стандарт издания отвечает главный редактор — Валерий Курземнек.

Материал редакции Зерокодера. Счёт по выдаче снят собственным прогоном 26 сентября 2026 года; цитаты источников приведены дословно. Обновлено: сентябрь 2026.

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

Что такое REST API одной фразой

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

В обзоре на mymeet.ai приводят наблюдение: «Когда разработчики говорят «у нас есть API» — в 90% случаев они имеют в виду REST API». То есть за аббревиатурой API в повседневной речи чаще всего стоит именно REST-подход.

Определение без жаргона: REST API — это набор адресов, по которым можно запросить или изменить данные, и набор правил, как эти запросы оформлять. Каждый адрес отвечает за один тип объектов: пользователи, заказы, встречи. Запрос всегда содержит метод (что сделать) и адрес (с чем сделать). Ответ содержит код состояния (получилось или нет) и сами данные.

Такой подход предложил в 2000 году в своей диссертации программист и исследователь Рой Филдинг, один из создателей протокола HTTP — так пишет блог Skillfactory. Термин REST ввёл Рой Филдинг в своей докторской диссертации в 2000 году — подтверждает Tproger. Один и тот же год, один и тот же автор, разные формулировки.

Собственный прогон редакции: скачали топ-10 Яндекса по запросу «api rest что это»: текст отдали 9 из 10. Медиана объёма читаемого текста топа — 2255 слов. Метку 2026 года несут 7 из 9 прочитанных страниц.

REST как стиль и API как интерфейс

Эти два слова часто сливают в одно, а означают они разное. REST — это архитектурный стиль, набор ограничений. API — это конкретный интерфейс, через который одна система обращается к другой. REST описывает, каким должен быть API, чтобы считаться RESTful.

Рой Филдинг описал 6 архитектурных ограничений, которым должна соответствовать система, чтобы считаться RESTful — так формулирует Tproger. В блоге Skillfactory встречается другая цифра: «У RESTful есть 7 принципов написания кода интерфейсов». Расхождение объяснимо: разные авторы по-разному считают принцип «код по требованию» и HATEOAS.

Проще говоря: REST — это чертёж, API — построенный по чертежу мост. Мост может быть построен и без чертежа, тогда он работает, но RESTful его не назовут. API существует и без REST: у SOAP свой протокол, у GraphQL свой язык запросов.

В блоге Практикума REST API описывают как архитектурный стиль взаимодействия между клиентом и сервером через HTTP, который определяет принципы построения API и стандартизирует обмен данными между системами. Это ровно та граница: REST задаёт форму взаимодействия, API — конкретные адреса и форматы.

Stateless в REST API: сервер не помнит клиента

Stateless — ключевое ограничение REST. Каждый запрос содержит всю информацию, нужную серверу для ответа. Сервер не хранит состояние клиента между запросами: получил запрос, обработал, забыл.

На Хабре разбирают это на примере прогноза погоды. Есть сервис, в котором уже реализована клиент-серверная архитектура, и клиент хочет получить сообщение о прогнозе погоды на завтра. Дальше авторы ставят вопрос: что было бы, если бы у нас не было Stateless? Сервер начал бы помнить, что вчера спрашивали про 20 июня, и достраивать ответ из памяти. Он понимает, что я у него спрашиваю про 21-е число и могу дать ответ на основе информации, хранимой у него в БД или в кэше — так описывают гипотетическое поведение.

В REST так не делают. Клиент в каждом запросе указывает всё: какой ресурс, какая версия, какой токен. Сервер не додумывает контекст. Это позволяет держать десятки серверов за балансировщиком: любой из них обработает любой запрос, потому что не зависит от предыдущего.

Практическое следствие: аутентификация передаётся в каждом запросе. Популярные способы: API-ключи (передаются в заголовке), OAuth 2.0 (токены доступа), JWT (JSON Web Token) — перечисляет Tproger. В примере из блога ProductStar заголовок выглядит так: Authorization: Bearer eyJhbGciOiJIUzI1NiIs. Токен едет с каждым запросом, сервер его проверяет и не запоминает.

Шесть принципов REST

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

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

Единообразие интерфейса — самый заметный принцип. Именно из-за него DELETE /api/tasks/1 считается хорошим REST, а /api/deleteTask — плохим, как пишет Tproger. Адрес называет ресурс, метод называет действие. Глагол в URL дублирует то, что уже сказано методом.

Шестой принцип — код по требованию — на практике почти не встречается. Серверы отдают данные. Поэтому в обиходе говорят о пяти работающих принципах, а шестой держат как теоретическую возможность.

Методы HTTP в REST API

Метод говорит, что сделать с ресурсом. Пять методов покрывают почти все операции с данными.

В базе знаний ELMA365 метод GET описан как Read (чтение) — получение данных без изменений, с примером GET /users/123. Там же приводят пару: GET /users/123 — получить пользователя, POST /users — создать нового.

Разница между PUT и PATCH в объёме изменений. PUT присылает объект целиком: чего нет в теле, то будет стёрто. PATCH присылает только изменяемые поля. В блоге Skillfactory приводят пример: REST API будет использовать метод PUT, а для его удаления — DELETE.

Ответы на эти методы описаны в помощи SpaceWeb. При успешном создании сервер отвечает кодом 201 Created и указывает адрес нового ресурса в специальном заголовке Location. Если обновление прошло успешно, сервер вернёт статус 200 OK или 204 No Content, а если ресурс был создан — статус 201 Created. При успешном удалении сервер возвращает статус 200 OK, 202 Accepted (если удаление происходит не сразу), или чаще всего 204 No Content.

Отдельно про DELETE: сервер обычно возвращает статус 204 No Content — данные удалены, тело ответа пустое, пишет Tproger. Тело пустое потому, что возвращать уже нечего.

Ресурс, эндпоинт и структура URL

Ресурс — это объект, с которым работают: пользователь, заказ, встреча. Эндпоинт — адрес, по которому этот ресурс доступен. URL собирается из коллекции и идентификатора.

На Хабре разбирают: здесь мы видим некоторый объект (ресурс) с конкретным идентификатором с номером 413. Я могу использовать HTTP-глагол GET для, того чтобы получить информацию о выступлении 413. Коллекция — это множество объектов, идентификатор — конкретный элемент внутри.

В блоге Практикума формулируют так: здесь users — это коллекция пользователей, а 123 — уникальный идентификатор конкретного пользователя. В mymeet.ai приводят цепочку: например, /meetings возвращает список встреч, /meetings/123 — конкретную встречу, /meetings/123/transcript — ее транскрипт. Вложенность показывает связь: транскрипт принадлежит встрече.

В ProductStar добавляют ещё один уровень: /users/123/orders — заказы конкретного пользователя. Так строятся адреса любой глубины: коллекция, идентификатор, вложенная коллекция.

Версионирование встраивают в URL. В mymeet.ai описывают: обычно реализуется через URL: /v1/meetings и /v2/meetings — разные версии одного endpoint. Клиенты, работающие на v1, продолжают работать даже когда выходит v2 с изменениями. Это позволяет менять API.

Структура запроса и ответа

Запрос состоит из метода, URL, заголовков и тела. Ответ — из кода состояния, заголовков и тела. Тело в обоих случаях чаще всего JSON.

Заголовки несут служебную информацию: тип содержимого, токен авторизации, язык. В блоге ProductStar показан заголовок авторизации: Authorization: Bearer eyJhbGciOiJIUzI1NiIs. Тело запроса при GET обычно пустое, при POST и PUT содержит объект.

Коды состояния делятся на группы. В блоге VK Cloud описывают: редактирование записи на сервере может отработать успешно (код 200), может быть заблокировано по соображениям безопасности (код 401 или 403), а то и вообще сломаться в процессе из-за ошибки сервера (код 500).

В блоге Практикума перечисляют: 500 Internal Server Error — ошибка на стороне сервера. Там же описывают пару для чтения: код ответа: 200 OK, если ресурс найден, или 404 Not Found, если нет.

Про лимиты в ELMA365 пишут: при работе с REST API многие сервисы (Google, VK, GitHub, Яндекс) устанавливают лимиты: например, 100 запросов в минуту. При превышении приходит 429 Too Many Requests. Там же дают рекомендацию по повтору: реализуйте повтор с экспоненциальной задержкой (retry‑backoff). Задержка растёт: экспоненциальная задержка: 1с, 2с, 4с, 8с … до максимального лимита.

Пример запроса и ответа в JSON

Разберём полный цикл: клиент создаёт задачу и получает ответ. Запрос:

POST /api/tasks
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIs.

{
  "title": "Проверить отчёт",
  "due": "2026-10-01"
}

Ответ сервера:

201 Created
Location: /api/tasks/42

{
  "id": 42,
  "title": "Проверить отчёт",
  "due": "2026-10-01",
  "createdAt": "2026-09-26T11:11:56Z"
}

В Tproger описывают похожий случай: сервер вернул статус 201 Created и добавил поля id и createdAt, которые генерируются автоматически. Клиент не присылает id — его назначает сервер.

Пример чтения из mymeet.ai: пример GET-запроса для получения транскрипта встречи выглядит так: клиент обращается к endpoint /meetings/123/transcript, передает API-ключ в заголовке Authorization и получает в ответ JSON с текстом. Тот же принцип: адрес называет ресурс, заголовок несёт ключ, тело несёт данные.

В помощи SpaceWeb описывают ответ на чтение: в ответ сервер отправит данные пользователя (обычно в формате JSON или XML) и статус-код 200 OK. Если пользователь с таким ID не найден, сервер вернет ошибку 404 Not Found.

RESTful API и REST API: в чём разница

REST — это стиль, RESTful — характеристика сервиса, который этому стилю соответствует. Формально «REST API» и «RESTful API» — одно и то же, но есть нюанс строгости.

На Хабре замечают: но в очень распространённом понимании соответствие 2-ому уровню часто называют RESTfull сервисом. Речь о модели зрелости Ричардсона: уровень 0 — один адрес для всего, уровень 1 — отдельные адреса ресурсов, уровень 2 — правильные HTTP-методы и коды, уровень 3 — HATEOAS со ссылками на связанные ресурсы.

На практике большинство сервисов живут на втором уровне: методы и коды соблюдены, гипермедиа-ссылки в ответах отсутствуют. Их называют RESTful, хотя строгий REST требует третьего уровня. Разница между REST API и RESTful API — в строгости соответствия.

Для разработчика это значит: если сервис использует правильные методы, коды и адреса ресурсов, его называют RESTful. Если в URL есть глаголы или один адрес на все операции — это уже не REST, даже если внутри HTTP.

REST против SOAP и GraphQL

REST — не единственный способ построить API. У него есть два заметных соседа, и у каждого своя ниша.

В Tproger дают справку: SOAP (Simple Object Access Protocol) — протокол, разработанный Microsoft в 1998 году. Там же: GraphQL — язык запросов от Facebook* (2015). В блоге Skillfactory добавляют: это отличает REST API от метода простого протокола доступа к объектам SOAP (Simple Object Access Protocol), созданного Microsoft в 1998 году.

В ELMA365 приводят хронологию: 1990-е: господство SOAP — сложного XML‑протокола. 2000: публикация REST Филдингом. 2000–2010: массовый переход на REST благодаря простоте, гибкости и использованию JSON. 2015+: появление альтернатив (GraphQL, gRPC), но REST остаётся доминирующим стандартом для веб‑API.

Границы применимости просты. SOAP выбирают там, где нужны строгие контракты и встроенные стандарты безопасности — например, в банковских и государственных интеграциях. GraphQL берут, когда клиенту нужна гибкая выборка полей и один запрос вместо нескольких. REST остаётся выбором по умолчанию для публичных веб-API и внутренних сервисов.

Ещё один сосед — gRPC. В ProductStar его описывают: gRPC — высокопроизводительный RPC-фреймворк от Google, использующий Protocol Buffers и HTTP/2. Его берут для внутренней связи микросервисов, где важна скорость.

Где применяют REST API

REST API — рабочий инструмент там, где одна система должна получать данные из другой. Сценариев несколько, и они пересекаются.

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

Интеграции между сервисами. В ELMA365 описывают: бизнесу — для автоматизации обмена данными между CRM, сайтом, 1С и банком. Там же в списке кейсов стоит холдинг рыбной промышленности: автоматизация проверки контрагентов — с 7 дней до 1 часа и экономия 40% бюджета на внешние сервисы.

Микросервисы. В помощи SpaceWeb перечисляют сферы: веб-приложения и сайты, облачные приложения и сервисы, микросервисы, аналитика и работа с данными, email-маркетинг. Микросервисная архитектура опирается на API как на способ связи между небольшими сервисами.

Аналитика и данные. Сервисы отдают статистику и выгрузки через API, чтобы её забирали в свои отчёты. В блоге Skillfactory пример разобран на REST API социальной сети X (бывший Twitter): запрос обратного геокодирования возвращает до 20 возможных местоположений по заданным координатам.

Внутренние системы. В ELMA365 описывают: HR, АХО, финансы и документооборот на ELMA365. API связывает учётные системы, порталы и внешние сервисы в один контур.

Тестирование REST API: Postman и Swagger

Проверять REST API удобнее инструментами. Браузер умеет только GET, а для POST, PUT и DELETE нужен клиент.

Postman — приложение для отправки запросов: выбирается метод, вводится URL, добавляются заголовки и тело, ответ приходит целиком. Swagger — способ описать API в машиночитаемом виде, из которого генерируется интерактивная документация: можно отправить запрос прямо со страницы описания.

Что проверяют при тестировании:

• Соответствие кодов состояния: в блоге Практикума упоминают соответствие кодов состояния (200 OK, 400 Bad Request и т.д.).
• Корректность тела ответа: поля, типы, обязательные значения.
• Обработку ошибок: что приходит при неверном токене, отсутствующем ресурсе, превышении лимита.
• Лимиты и повторы: в ELMA365 советуют реализуйте повтор с экспоненциальной задержкой (retry‑backoff).
• Нагрузку: в ProductStar выделяют нагрузочные тесты — проверку производительности под нагрузкой.

Отдельно проверяют авторизацию. В блоге Практикума упоминают OAuth 2.0 — стандарт для безопасной авторизации через токены доступа. В ProductStar перечисляют варианты: Basic Auth — логин и пароль в заголовке в base64-кодировке, OAuth 2.0 / OpenID Connect — стандарт для делегированного доступа.

Частые вопросы

Что такое REST API простыми словами?
Это способ, которым одна программа просит данные у другой по веб-адресам. Каждый адрес отвечает за свой тип объектов, а метод запроса говорит, что сделать: прочитать, создать, изменить или удалить. Ответ приходит в формате JSON с кодом состояния. Такой подход предложил Рой Филдинг в 2000 году.

Чем REST API отличается от обычного API?
API — это любой интерфейс взаимодействия между программами. REST — набор архитектурных ограничений, которым этот интерфейс может соответствовать. Если API построен по правилам REST, его называют RESTful. В обзоре на mymeet.ai замечают, что в 90% случаев под словом API имеют в виду именно REST API.

Что такое endpoint в REST API?
Endpoint — это адрес, по которому доступен ресурс. Он собирается из коллекции и идентификатора: /meetings возвращает список встреч, /meetings/123 — конкретную встречу. Вложенные адреса показывают связи: /meetings/123/transcript — транскрипт встречи. Версию встраивают в URL: /v1/meetings и /v2/meetings.

Что такое stateless в REST API?
Это принцип, по которому сервер не хранит состояние клиента между запросами. Каждый запрос содержит всё нужное для ответа: адрес ресурса, токен, параметры. Сервер обработал запрос и забыл о нём. Поэтому за балансировщиком может стоять несколько серверов, и любой обработает любой запрос.

Как REST API возвращает ошибки?
Через коды состояния HTTP. 400 Bad Request означает ошибку на стороне клиента, 401 — проблему с авторизацией, 404 — отсутствие ресурса, 429 — превышение лимита запросов, 500 — сбой на сервере. В ELMA365 при превышении лимита советуют повтор с экспоненциальной задержкой: 1с, 2с, 4с, 8с.