Что такое REST API простыми словами: принципы, методы и примеры

Вы наверняка сталкивались с REST API, даже если не знали об этом. Каждый раз, когда мобильное приложение загружает ленту новостей, а сайт показывает прогноз погоды — за кулисами работает именно REST API. Разберёмся, как устроена эта технология и почему она стала стандартом веб-разработки.

REST API (Representational State Transfer Application Programming Interface) — это архитектурный стиль взаимодействия между клиентом и сервером через протокол HTTP. Клиент отправляет запрос на определённый URL, а сервер возвращает данные — чаще всего в формате JSON. REST не является протоколом или стандартом: это набор архитектурных принципов, которым следует разработчик при проектировании API.

Что означает REST — 6 принципов архитектуры

Термин REST ввёл Рой Филдинг в своей докторской диссертации в 2000 году. Он описал 6 архитектурных ограничений, которым должна соответствовать система, чтобы считаться RESTful.

1. Клиент-сервер — клиент и сервер разделены. Клиент отвечает за интерфейс, сервер — за хранение данных и бизнес-логику. Это позволяет развивать их независимо
2. Отсутствие состояния (Stateless) — каждый запрос содержит всю информацию, необходимую для его обработки. Сервер не хранит контекст между запросами
3. Кэширование — ответы сервера могут быть помечены как кэшируемые. Это снижает нагрузку и ускоряет работу клиента
4. Единообразный интерфейс — все ресурсы доступны через стандартные HTTP-методы и имеют предсказуемые URL. Это главное отличие REST от других подходов
5. Многослойная архитектура — между клиентом и сервером могут находиться промежуточные слои: балансировщики, прокси, кэш-серверы. Клиент не знает, общается ли он напрямую с сервером
6. Код по запросу (необязательно) — сервер может передавать клиенту исполняемый код, например JavaScript. Этот принцип — единственный необязательный из шести

HTTP-методы — GET, POST, PUT, DELETE

REST API использует стандартные HTTP-методы для операций над ресурсами. Каждый метод соответствует определённому действию — это называется CRUD (Create, Read, Update, Delete).

GET — получение данных

Запрашивает ресурс с сервера. Не изменяет данные — только читает.

			GET /api/users/42 HTTP/1.1
Host: example.com
Accept: application/json
		

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

			{
  "id": 42,
  "name": "Алексей",
  "email": "alexey@example.com",
  "role": "developer"
}
		

POST — создание ресурса

Создаёт новый ресурс на сервере. Данные передаются в теле запроса.

			POST /api/users HTTP/1.1
Host: example.com
Content-Type: application/json

{
  "name": "Мария",
  "email": "maria@example.com",
  "role": "designer"
}
		

PUT — обновление ресурса

Полностью заменяет ресурс новыми данными. Если нужно обновить одно поле — используют PATCH.

			PUT /api/users/42 HTTP/1.1
Host: example.com
Content-Type: application/json

{
  "name": "Алексей",
  "email": "alexey-new@example.com",
  "role": "senior developer"
}
		

DELETE — удаление ресурса

Удаляет ресурс с сервера.

			DELETE /api/users/42 HTTP/1.1
Host: example.com
		

Сервер обычно возвращает статус 204 No Content — данные удалены, тело ответа пустое.

Как выглядит REST API на практике — пример CRUD

Представим, что мы проектируем API для управления задачами (to-do list). Вот как будет выглядеть набор эндпоинтов:

			GET    /api/tasks        — получить список всех задач
GET    /api/tasks/1      — получить задачу с id=1
POST   /api/tasks        — создать новую задачу
PUT    /api/tasks/1      — обновить задачу с id=1
DELETE /api/tasks/1      — удалить задачу с id=1
		

Обратите внимание на структуру URL. Ресурс — это существительное во множественном числе (/tasks), а действие определяется HTTP-методом, а не URL. Именно поэтому /api/deleteTask — это плохой REST, а DELETE /api/tasks/1 — хороший.

Пример запроса на создание задачи и ответа сервера:

			// Запрос
POST /api/tasks
Content-Type: application/json

{
  "title": "Изучить REST API",
  "completed": false
}

// Ответ — 201 Created
{
  "id": 7,
  "title": "Изучить REST API",
  "completed": false,
  "createdAt": "2026-03-28T12:00:00Z"
}
		

Сервер вернул статус 201 Created и добавил поля id и createdAt, которые генерируются автоматически.

REST vs SOAP vs GraphQL

REST — не единственный способ построить API. Сравним его с двумя другими популярными подходами.

SOAP (Simple Object Access Protocol) — протокол, разработанный Microsoft в 1998 году. Использует XML для запросов и ответов, требует строгую схему (WSDL). SOAP популярен в корпоративных системах и банках, где важна формальная спецификация и встроенная безопасность (WS-Security). Но он значительно тяжелее REST: XML-конверты, обязательные заголовки, сложная настройка.

GraphQL — язык запросов от Facebook* (2015). Клиент сам описывает, какие данные ему нужны, в одном запросе. Это решает проблему over-fetching (когда REST возвращает лишние поля) и under-fetching (когда нужно несколько запросов). Но GraphQL сложнее в реализации и отладке, а кэширование требует дополнительных усилий.

* Meta признана экстремистской и запрещена в России

• REST — простой, стандартный, подходит для большинства задач. Лучший выбор, если API публичное или команда небольшая
• SOAP — для корпоративных интеграций с жёсткими требованиями к безопасности и контрактам
• GraphQL — для сложных клиентов, которым нужна гибкость в выборке данных (мобильные приложения, SPA)

Заключение

REST API — это фундамент современной веб-разработки. Его сила — в простоте: стандартные HTTP-методы, понятные URL, предсказуемые ответы. Именно поэтому REST используют такие компании, как Google, GitHub, Stripe и тысячи других.

Если вы только начинаете работу с API — попробуйте отправить GET-запрос к любому публичному API (например, GitHub API) через curl или Postman. Это лучший способ понять, как всё работает на практике.

Чтобы глубже разобраться во взаимодействии клиента и сервера, рекомендуем нашу статью Frontend и Backend: как они взаимодействуют.