REST API — это способ обмена данными между программами через HTTP по набору архитектурных правил REST. Такой интерфейс помогает клиенту запрашивать ресурсы на сервере, а серверу — возвращать данные в предсказуемом формате.
Термин REST расшифровывается как Representational State Transfer. На практике его чаще связывают с веб-сервисами, где есть адреса ресурсов, HTTP-методы, коды ответа и форматы данных вроде JSON.
Содержание статьи
Как определить REST API
REST API — это API, которое строится вокруг ресурсов, их URI и стандартных HTTP-методов. Главная идея проста: клиент обращается к ресурсу по адресу и выполняет действие без хранения состояния запроса на стороне сервера.
API, или интерфейс программирования приложений, нужен для того, чтобы одна система могла обращаться к функциям или данным другой. В модели REST одна программа выступает клиентом, другая — сервером. Клиент запрашивает ресурс, сервер его отдает, изменяет или удаляет, если это разрешено.
Ключевая особенность REST API — единообразный подход к работе с ресурсами. Если есть ресурс пользователя, у него должен быть понятный адрес, а действия с ним должны вызываться стандартными средствами HTTP.
На чём основан REST
REST опирается на набор архитектурных ограничений, которые делают API предсказуемым, масштабируемым и удобным для интеграции. Если эти ограничения не соблюдаются, интерфейс обычно не относят к REST в строгом смысле.
Единый интерфейс
Один и тот же ресурс должен запрашиваться единообразно, независимо от клиента. Это означает понятные URI, стандартные методы и согласованный формат ответов.
Если данные пользователя доступны по одному адресу, не должно быть нескольких несвязанных путей к одному и тому же объекту без явной причины. Это упрощает документацию, интеграцию и поддержку.
Независимость клиента и сервера
Клиент и сервер должны быть слабо связаны. Клиенту достаточно знать адрес ресурса и формат взаимодействия, а серверу не нужно знать устройство интерфейса клиента.
Такой подход позволяет менять фронтенд и бэкенд отдельно. Например, мобильное приложение, веб-интерфейс и внутренний сервис могут обращаться к одному API без прямой зависимости друг от друга.
Отсутствие состояния на сервере
REST API считается stateless, то есть каждый запрос должен содержать всё необходимое для обработки. Сервер не должен хранить состояние предыдущих запросов клиента между вызовами.
Если клиенту нужен доступ к защищённому ресурсу, он передаёт данные авторизации в каждом нужном запросе. Это упрощает масштабирование, потому что любой серверный экземпляр может обработать запрос без привязки к прошлой сессии.
Кэширование
Ответы REST API могут кэшироваться, если это допустимо для конкретного ресурса. Сервер должен явно сообщать, можно ли хранить ответ в кэше и на каких условиях.
Кэш снижает число повторных запросов и ускоряет работу клиента. Для часто запрашиваемых и редко меняющихся данных это особенно полезно.
Слоистая архитектура
Взаимодействие клиента и сервера может проходить через промежуточные слои. Это могут быть прокси, балансировщики нагрузки, шлюзы или кэширующие узлы.
Клиенту не обязательно знать, разговаривает ли он напрямую с конечным сервером. Сервер, в свою очередь, тоже не обязан учитывать внутренний маршрут запроса.
Код по запросу
Это необязательное ограничение REST. В некоторых случаях сервер может передавать исполняемый код, который клиент запускает по необходимости.
На практике в современных веб-API этот принцип упоминается реже, чем остальные. Но в исходной архитектурной модели REST он присутствует.
Как работает REST API
REST API обычно работает через HTTP-запросы к ресурсам. Клиент отправляет запрос по URI, указывает метод, заголовки и при необходимости тело запроса, а сервер возвращает данные и HTTP-статус.
Чаще всего REST API используют для базовых операций с данными, которые связывают с моделью CRUD: создание, чтение, обновление и удаление. Для этих действий применяют стандартные HTTP-методы.
| HTTP-метод | Типичное действие |
| GET | Получить ресурс или список ресурсов |
| POST | Создать новый ресурс |
| PUT | Обновить ресурс целиком |
| DELETE | Удалить ресурс |
Представление ресурса может передаваться в разных форматах, но чаще всего используется JSON. Он удобен тем, что читается человеком и легко обрабатывается программами на разных языках.
Помимо тела запроса и ответа, большую роль играют заголовки. В них передают данные авторизации, метаданные, правила кэширования, тип содержимого и другую служебную информацию.
Что такое ресурс и URI в REST API
Ресурс — это сущность, с которой работает API: пользователь, заказ, файл, статья или любой другой объект. URI — это адрес, по которому этот ресурс доступен.
Если API построен аккуратно, структура адресов отражает логику предметной области. Например, коллекция ресурсов и отдельный объект обычно имеют разные URI. Это делает интерфейс понятнее без длинных пояснений.
REST API строится вокруг ресурсов, а не вокруг произвольных команд. Вместо вызова действий в духе getUserData или deleteOrderById обычно используются адрес ресурса и HTTP-метод.
Какие данные передаются в запросах и ответах
Запросы и ответы REST API состоят не только из данных в теле. Не менее важны заголовки, параметры запроса, URI и коды состояния HTTP.
Код ответа показывает результат обработки. Например, успешное выполнение, ошибка авторизации, отсутствие ресурса или некорректные входные данные. Это помогает клиенту правильно интерпретировать ответ без догадок.
- URI указывает, к какому ресурсу обращается клиент.
- HTTP-метод задаёт тип действия.
- Заголовки передают служебные данные: авторизацию, тип контента, правила кэширования.
- Параметры помогают фильтровать, сортировать и уточнять запрос.
- Тело запроса содержит данные для создания или изменения ресурса.
- HTTP-статус сообщает итог обработки.
Чем REST API отличается от других API-подходов
REST API отличается тем, что использует архитектурные ограничения REST и опирается на стандартные возможности HTTP. Другие подходы могут задавать более жёсткие правила обмена или по-другому описывать доступ к данным.
Например, некоторые API строятся вокруг строго определённого формата сообщений и фиксированных контрактов. REST обычно даёт больше свободы в реализации, но эта свобода требует аккуратного проектирования. Без ясной структуры адресов, статусов и форматов ответов интерфейс быстро становится запутанным.
По этой причине REST часто описывают как архитектурный стиль, а не как жёсткий протокол.
Какие принципы помогают сделать REST API понятным
Понятный REST API использует предсказуемые адреса ресурсов, корректные HTTP-методы, ясные коды ответа и единый формат данных. Чем меньше исключений из правил, тем проще интеграция.
Для описания API часто применяют OpenAPI Specification, или OAS. Эта спецификация помогает формально задать доступные конечные точки, параметры, операции и способы авторизации, чтобы другие разработчики и инструменты могли корректно работать с интерфейсом.
Есть и базовые практики, без которых API быстро начинает ломать ожидания клиентов.
- Использовать согласованные URI для коллекций и отдельных ресурсов.
- Применять HTTP-методы по назначению.
- Возвращать понятные HTTP-статусы.
- Поддерживать единый формат ответов и сообщений об ошибках.
- Описывать параметры, ограничения и авторизацию в документации.
Как защищают REST API
Безопасность REST API строится на шифровании передачи данных, проверке прав доступа и валидации входящих запросов. Для этого обычно используют HTTPS, механизмы авторизации и проверку параметров.
Если API работает с учётными данными, пароли хранят не в открытом виде, а с применением алгоритмов хеширования. Для разграничения доступа могут использоваться OAuth 2.0, токены и другие схемы авторизации, в зависимости от архитектуры системы.
Дополнительно сервер может ограничивать срок действия запроса по временной метке в заголовках, отклонять просроченные запросы и проверять корректность входных данных. В этой же группе мер часто упоминают JSON Web Token, если система использует токены такого типа.
Где REST API применяется чаще всего
REST API чаще всего используют там, где разным системам нужно обмениваться данными через веб. Это могут быть сайты, мобильные приложения, серверные сервисы, базы данных и компоненты микросервисной архитектуры.
Причина проста: HTTP уже повсеместно используется, а структура REST понятна многим инструментам и командам разработки. Один и тот же API может обслуживать несколько клиентов с разными интерфейсами, если они понимают общие правила доступа к ресурсам.
REST API особенно удобен для интеграций, где важны предсказуемость запросов, разделение клиента и сервера и поддержка стандартной веб-инфраструктуры.
Когда термин REST API используют слишком широко
Не каждый HTTP-сервис с JSON автоматически является REST API. Чтобы интерфейс действительно соответствовал REST, он должен следовать ключевым ограничениям этого архитектурного стиля.
На практике термин часто используют шире и называют REST почти любой веб-API с методами GET и POST. Это привычно, но не всегда точно. Если у интерфейса нет явной работы с ресурсами, нарушена stateless-модель или игнорируются базовые принципы HTTP, корректнее говорить просто о веб-API.
