REST API
REST API — это архитектурный стиль (набор правил) взаимодействия между клиентом и сервером через HTTP. Он используется для обмена данными в веб‑разработке, мобильных приложениях и микросервисах. REST API что это простыми словами: способ, при котором одна программа отправляет HTTP‑запрос (GET, POST, PUT, DELETE), а другая возвращает данные (чаще всего в формате JSON).
Как работает REST API: клиент обращается к эндпоинту (URL), сервер обрабатывает запрос и возвращает ответ со статус‑кодом и телом. Для чего нужен REST API — для интеграции систем: сайт ↔ CRM, приложение ↔ сервер, сервис ↔ платёжный шлюз.
В этом руководстве разберём примеры REST API, научимся работать с REST API на практике и подробно расскажем, как защитить REST API от атак и утечек данных.
Краткое содержание:
- Что такое REST API
- История
- Для чего нужен
- Как работает
- Как защитить
- Версионирование
- Ошибки
- Rate limiting и retry
- Сравнение
- FAQ
Что такое REST API: простыми словами и расшифровка
REST API — это способ взаимодействия между приложениями через HTTP‑запросы и ответы, где каждый запрос обрабатывается независимо (без сохранения состояния на сервере).
REST расшифровывается как Representational State Transfer («передача состояния представления»). Это архитектурный стиль, в котором данные представлены как ресурсы (users, orders, products), доступные по уникальному URL. Клиент получает или изменяет ресурс, отправляя HTTP‑метод (GET, POST, PUT, DELETE) к этому URL. Например, GET /users/123 — получить пользователя, POST /users — создать нового. Ответ сервера возвращается в JSON или XML.
Ключевое свойство: stateless (отсутствие состояния). Сервер не хранит информацию о предыдущих запросах клиента — каждый запрос содержит все необходимые данные для его обработки.
История появления REST API
REST предложен в 2000 году Роем Филдингом — одним из авторов протокола HTTP. В своей диссертации он описал REST как набор архитектурных ограничений для создания масштабируемых веб‑сервисов.
Ключевые вехи развития:
- 1990-е: господство SOAP — сложного XML‑протокола.
- 2000: публикация REST Филдингом.
- 2000–2010: массовый переход на REST благодаря простоте, гибкости и использованию JSON.
- 2015+: появление альтернатив (GraphQL, gRPC), но REST остаётся доминирующим стандартом для веб‑API.
Для чего нужен REST API
REST API нужен для интеграции систем и передачи данных. Бизнесу — для автоматизации обмена данными между CRM, сайтом, 1С и банком. Вот пять ключевых сценариев, где он незаменим:
Применение REST API
| Применение | Примеры |
|---|---|
| Веб‑интеграции | Интернет‑магазин подключает платёжный шлюз (банковский API) через REST. Frontend ↔ backend |
| Мобильные приложения | Приложение такси отправляет запросы на сервер (создать заказ, отследить водителя). Приложение ↔ сервер |
| Микросервисы | Внутри компании сервис заказов обменивается данными с сервисом доставки. Сервис ↔ сервис |
| Государственные системы | ЕГИССО, Госуслуги, ЕГРН — предоставляют REST API для бизнеса |
| Публичные API | Яндекс Карты, VK, OpenWeather — тысячи сервисов отдают данные через REST |
Как работает REST API
REST API работает по модели «запрос–ответ» (клиент-сервер): клиент (браузер, мобильное приложение, бэкенд) отправляет HTTP-запрос к определённому URL с указанием метода. Сервер обрабатывает запрос и возвращает HTTP‑ответ с кодом статуса и телом.
Основные элементы REST API
REST API строится на четырёх элементах: клиент (отправитель запроса), сервер (обработчик), эндпоинт (URL ресурса) и формат ответа (обычно JSON).
| Элемент | Описание |
|---|---|
| Клиент | отправляет запрос |
| Сервер | обрабатывает |
| Endpoint | URL ресурса |
| Ответ | JSON |
Основные компоненты запроса
HTTP‑запрос к REST API состоит из метода (GET, POST), URL эндпоинта, заголовков (например, Content-Type) и опционального тела с данными.
- HTTP метод — действие (GET, POST, PUT, DELETE)
- URL — адрес ресурса (
/users,/orders/123) - Заголовки — метаданные (
Content-Type: application/json,Authorization: Bearer token) - Тело — данные для POST/PUT (в JSON)
Пример GET‑запроса через cURL:
curl https://api.example.com/users/123Пример ответа сервера (JSON):
{
"id": 123,
"name": "Иван Петров",
"email": "ivan@example.com"
}Endpoint в REST API
Endpoint — это URL, по которому доступен ресурс API.
Пример: GET /users/1
6 основных методов REST API (CRUD)
HTTP методы определяют действия с данными.
| Метод | Действие CRUD | Когда использовать | Пример |
|---|---|---|---|
| GET | Read (чтение) | Получение данных (без изменений) | GET /users/123 |
| POST | Create (создание) | Создание нового ресурса | POST /users (тело: {"name":"Новый"}) |
| PUT | Update (полная замена) | Обновление всего ресурса (нужно передать все поля) | PUT /users/123 |
| PATCH | Update (частичное обновление) | Частичное изменение ресурса (только указанные поля) | PATCH /users/123 (тело: {"email":"new@mail.com"}) |
| DELETE | Delete | Удаление ресурса | DELETE /users/123 |
| OPTIONS | Metadata | Получение списка HTTP методов, поддерживаемых для эндпоинта | OPTIONS /users/123 (ответ: Allow: GET, PUT, PATCH, DELETE, OPTIONS) |
Структура HTTP запроса и ответа
HTTP запрос включает стартовую строку с методом и URL, заголовки и тело. HTTP ответ содержит код статуса, заголовки и тело с данными (обычно JSON).
Пример POST‑запроса (создание пользователя):
POST /users HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJIUzI1...
{"name": "Мария", "email": "m@example.com"}Пример ответа (201 Created):
HTTP/1.1 201 Created
Content-Type: application/json
Location: /users/456
{"id": 456, "name": "Мария", "email": "m@example.com"}HTTP коды статусов REST API
Коды статуса HTTP показывают результат запроса: 2xx — успех, 4xx — ошибка клиента (например, 404 — не найдено), 5xx — ошибка сервера.
| Код | Категория | Значение | Когда возвращается |
|---|---|---|---|
| 200 | Успех | OK | GET, PUT прошли успешно |
| 201 | Успех | Created | Ресурс создан (POST) |
| 204 | Успех | No Content | DELETE выполнен, тело пустое |
| 301 | Перенаправление (Редирект) | Moved Permanently | Ресурс перемещён на новый URL |
| 400 | Ошибка клиента | Bad Request | Неверный синтаксис запроса |
| 401 | Ошибка клиента | Unauthorized | Нет аутентификации |
| 403 | Ошибка клиента | Forbidden | Нет прав доступа (авторизация не пройдена) |
| 404 | Ошибка клиента | Not Found | Ресурс не найден |
| 429 | Ошибка клиента | Too Many Requests | Превышен лимит запросов |
| 500 | Ошибка сервера | Internal Server Error | Непредвиденная ошибка на сервере |
| 503 | Ошибка сервера | Service Unavailable | Сервер временно недоступен |
HTTP headers в REST API: что это и зачем нужны
HTTP‑заголовки передают метаданные запроса: тип данных, авторизацию, управление кэшем и др.
| Заголовок (Header) | Назначение | Перевод |
|---|---|---|
| Authorization | Передача учетных данных для аутентификации (например, Bearer | Авторизация (предоставление прав доступа) |
| Content-Type | Определение формата данных, отправляемых на сервер (обычно application/json) | Тип контента (формат тела запроса) |
| Accept | Определение формата данных, который клиент ожидает получить от сервера | Принимаемый тип (формат ответа от сервера) |
| User-Agent | Идентификация клиента (браузер, приложение, библиотека) | Агент пользователя |
| Cache-Control | Управление механизмами кэширования (например, no-cache) | Управление кэшем |
| Host | Доменное имя сервера (обязательно для HTTP/1.1) | Хост (адрес сервера) |
Как использовать REST API
Использование REST API — это последовательность: endpoint → метод → запрос → ответ.
Пошаговая работа с REST API:
- Найти endpoint (конкретный URL-адрес) API
- Выбрать HTTP метод
- Добавить HTTP-заголовки (Authorization, Content-Type и т.д.)
- Отправить запрос
- Обработать ответ
Работа с REST API: реальные примеры
Пример 1: GET запрос
curl https://api.example.com/users/1Ответ:
{
"id": 1,
"name": "Ivan"
}Пример 2: POST запрос
curl -X POST -H "Content-Type: application/json" -d '{"name":"Anna"}' https://api.example.com/usersПример 3: запрос с авторизацией (Bearer Token)
curl -H "Authorization: Bearer TOKEN" https://api.example.com/ordersПример 4: JavaScript (fetch)
fetch('https://api.example.com/users')
.then(res => res.json())
.then(data => console.log(data));Пример 5: Python
import requests
response = requests.get('https://api.example.com/users')
print(response.json())Российские примеры REST API
- VK API — получение данных пользователей, записей стен.
- Яндекс API — карты, расписания, переводчик.
- API Госуслуг — проверка статуса документов (для юрлиц).
Пример REST API с токеном: реальный кейс
После успешного входа сервер возвращает токен, который клиент использует в заголовке Authorization для доступа к защищённым эндпоинтам.
{
"token": "abc123",
"user": {
"id": 1,
"email": "test@mail.com"
}
}👉 Сервер выдаёт токен → клиент отправляет его в Authorization header.
Как защитить REST API — 6 лучших практик
Защита REST API включает аутентификацию, авторизацию и защиту от атак и утечек. Разберем все по порядку.
Методы аутентификации
| Метод | Описание |
|---|---|
| JWT (JSON Web Token) | Токен с подписью, содержит данные о пользователе и срок действия. Идеален для stateless‑архитектур. |
| OAuth 2.0 | Стандарт для делегированного доступа (например, «Войти через Google»). |
| API‑keys | Простые ключи (строки) для служебных интеграций. |
Как защитить rest api с помощью JWT: после логина сервер выдаёт токен, клиент отправляет его в заголовке Authorization: Bearer <token>. Сервер проверяет подпись и извлекает данные без обращения к БД.
Пример JWT авторизации
curl -H "Authorization: Bearer eyJhbGciOiJIUzI1..." https://api.site.comОсновные атаки на REST API: распространенные уязвимости
REST API уязвим для шести основных атак: BOLA (доступ к чужим данным), Brute force (подбор паролей), DDoS, Injection, Mass Assignment и CSRF. Ниже — их описание и защита.
| 🎯 Атака | 📖 Описание | ⚠️ Чем опасна | 🛡️ Как защититься |
|---|---|---|---|
| BOLA (Broken Object Level Authorization) | Доступ к чужим данным из‑за отсутствия проверки прав на уровне объекта | Злоумышленник меняет ID в запросе (/user/123 → /user/124) и получает чужие данные | Проверяйте права доступа в каждом эндпоинте, используйте RBAC/ABAC |
| Brute force (метод «грубой силы») | Подбор паролей, токенов, API‑ключей перебором | Взлом учётных записей, компрометация доступа | Rate limiting, CAPTCHA, сложные JWT с коротким TTL |
| DDoS (Distributed Denial of Service) | Массовые запросы с множества IP для перегрузки API | Сервер становится недоступен, рост затрат | Rate limiting, CDN с защитой, WAF |
| Injection | Внедрение вредоносного кода в запросы (SQL, NoSQL, Command, LDAP) | Утечка данных, удаление таблиц, выполнение команд | Валидация и экранирование входных данных, параметризованные запросы / ORM |
| Mass Assignment | Автоматическое привязывание переданных полей к внутренним объектам без фильтрации | Злоумышленник передаёт поле "is_admin": true и получает права администратора | Используйте DTO или разрешённые поля ($fillable / @Column(update: false)) |
| CSRF (Cross-Site Request Forgery) | Выполнение нежелательных действий от имени аутентифицированного пользователя | Смена email, пароля, перевод средств — без ведома пользователя | Анти-CSRF токены, SameSite cookies, проверка Referer/Origin, JWT без сессий |
Защита REST API: Лучшие практики безопасности
| Практика | Описание |
|---|---|
| HTTPS с TLS 1.2+ | Шифрование всего трафика (защита от перехвата) |
| Аутентификация | Используйте OAuth 2.0, JWT или API‑keys. Никогда не передавайте пароли в открытом виде |
| Авторизация | Проверяйте права доступа в каждом эндпоинте (особенно защита от BOLA) |
| Rate limiting | Ограничьте количество запросов от одного IP/пользователя (защита от DDoS и брутфорса) |
| Валидация входных данных | Проверяйте типы, длины, экранируйте спецсимволы (защита от инъекций) |
| Middleware проверка запросов | Централизованный слой (логирование, CORS, проверка заголовков, фильтрация опасных шаблонов) |
Версионирование REST API
Версионирование позволяет изменять API без поломки старых клиентов. Чаще всего версию указывают в URL (/v1/users, /v2/users) или в заголовке Accept: version=1. Это важно для долгоживущих публичных API.
Ошибки при работе с REST API
Частые ошибки интеграции API возникают из-за неправильных запросов, неверной обработки ответов или игнорирования стандартов HTTP. Ниже — полный список проблем, их причин, последствий и решений.
| № | Ошибка / Статус | Причина | Последствия | ✅ Как избежать / Решение |
|---|---|---|---|---|
| 1 | Игнорирование HTTP статусов | Клиент не анализирует коды 2xx/4xx/5xx | Программа продолжает работу с ошибочными данными | Всегда проверяйте response.status_code перед обработкой тела |
| 2 | 400 Bad Request | Неверный JSON, синтаксическая ошибка в теле запроса | Сервер не понял запрос | Валидируйте JSON перед отправкой, используйте схемы |
| 3 | 401 Unauthorized | Отсутствует или истёк токен, неверный API‑ключ | Доступ запрещён | Добавляйте заголовок Authorization: Bearer |
| 4 | 429 Too Many Requests | Превышен лимит запросов (rate limiting) | Блокировка IP или пользователя на время | Реализуйте повтор с экспоненциальной задержкой (retry‑backoff) |
| 5 | Timeout (таймаут) | Сервер не отвечает в заданный промежуток | Зависание приложения, неполучение данных | Устанавливайте таймауты (например, timeout=5 секунд) |
| 6 | Хранение секретов в коде | API‑ключи, пароли, токены зашиты в исходниках | Утечка секретов в репозиторий | Используйте переменные окружения (env) или секретные менеджеры |
| 7 | Неверный Content‑Type | Отправка JSON без заголовка Content-Type: application/json | Ошибка 415 Unsupported Media Type | Всегда указывайте Content-Type: application/json для JSON‑запросов |
| 8 | Отсутствие обработки сетевых ошибок | Не ловятся исключения (DNS, разрыв соединения) | Падение приложения, потеря данных | Используйте try/catch, повторные попытки, fallback логику |
💡 Совет: при разработке всегда тестируйте API через Postman или curl, проверяя коды статусов и заголовки. Для автоматических запросов (Python, JS) настраивайте перехватчики (interceptors) для логирования ошибок.
Rate limiting и retry — как правильно обрабатывать ограничения
Rate limit — это ограничение количества запросов от клиента за единицу времени. Retry — повторная отправка запроса при временной ошибке.
При работе с REST API многие сервисы (Google, VK, GitHub, Яндекс) устанавливают лимиты: например, 100 запросов в минуту. При превышении сервер возвращает код 429 Too Many Requests и блокирует дальнейшие запросы на некоторое время.
Как правильно обрабатывать:
| Механизм | Назначение | Как реализовать |
|---|---|---|
| Rate limit | Ограничение числа запросов от клиента | Следите за заголовками ответа: X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset |
| Retry | Повтор запроса после ошибки (429, 5xx) | Используйте библиотеки с автоматическим повтором (например, requests с Retry в Python или axios-retry в JS) |
| Backoff | Задержка перед повторным запросом | Экспоненциальная задержка: 1с, 2с, 4с, 8с … до максимального лимита |
REST vs SOAP vs GraphQL — сравнение технологий
REST — проще и быстрее SOAP, используется в большинстве веб‑API. GraphQL даёт гибкость в выборе полей, но сложнее в реализации.
Сравнение API по ключевым характеристикам:
| Критерий | REST | SOAP | GraphQL |
|---|---|---|---|
| Статус | Архитектурный стиль | Строгий протокол | Язык запросов + runtime |
| Особенности | Простой | Сложный | Гибкий |
| Форматы данных | JSON, XML, YAML, HTML | Только XML | JSON (запросы/ответы) |
| Количество запросов | Может потребоваться несколько (проблема N+1) | Один запрос = одно действие | Один запрос может собрать множество ресурсов |
| Передача данных | Клиент получает всё (избыточность) | Строго определённая структура | Клиент запрашивает только нужные поля |
| Производительность | Высокая (легковесный) | Низкая (много XML‑обёрток) | Средняя (зависит от сложности запроса) |
| Кэширование | Отличное (через HTTP‑кеш) | Ограниченное | Ограниченное |
| Безопасность | Через HTTPS, OAuth, JWT | Встроенная WS‑Security | Аналогично REST |
| Сложность реализации | Низкая | Высокая | Средняя / Высокая |
| Где применяется | Веб‑API, мобильные приложения, микросервисы | Корпоративные системы, банки (устаревшие), ACID‑транзакции | Сложные клиенты с разными потребностями |
Заключение
REST API — основной стандарт обмена данными в 2026 году. Он используется в API сервисах, микросервисах, backend разработке и интеграциях.
Используйте эту статью как шпаргалку для разработки или обучения.
📚 Читайте также:
Часто задаваемые вопросы о REST API - FAQ
Что такое REST API?
Это способ взаимодействия программ через HTTP.
Что такое REST API простыми словами?
Это правила, по которым программы общаются через интернет: одна отправляет запрос, другая отвечает данными.
Для чего нужен REST API?
Для интеграции сайтов с платёжками, мобильными приложениями, 1С, госуслугами.
Как работает REST API?
Клиент отправляет запрос → сервер отвечает.
Как использовать REST API?
Через HTTP запросы (curl, fetch, Python).
Как защитить REST API?
Используйте HTTPS, JWT или OAuth 2.0, ограничивайте запросы, валидируйте входные данные.
Чем REST отличается от HTTP?
HTTP — протокол передачи данных, REST — стиль использования HTTP с методами и статусами.
Актуален ли REST в 2026 году?
Да, это стандарт для подавляющего большинства веб‑сервисов и открытых API.