Мы уже разобрались, как устроены фронтенд и бэкенд, как работает клиент-серверная модель, где хранятся данные. Но остался важный вопрос: как именно фронтенд и бэкенд обмениваются информацией? Какой язык они используют для общения?

Ответ: через API (Application Programming Interface), а конкретнее – через REST API. Это стандартный способ, которым пользуется большинство современных веб-приложений.

Если вы когда-нибудь планируете заниматься веб-разработкой или просто хотите понимать, как устроены сайты изнутри – эта статья для вас. Разберём всё простым языком, с примерами из жизни.

Что такое API?

API (Application Programming Interface) – это набор правил и инструментов, которые позволяют одной программе взаимодействовать с другой.

Можно сравнить API с:

Аналогия с рестораном (снова!)

Представьте:

• Вы (клиент) – хотите поесть, но не можете зайти на кухню и сами готовить. Есть правила.
• Меню – это интерфейс (API). В меню написано, что можно заказать, в каком формате (суп, основное блюдо, десерт), какие параметры указать (размер порции, степень прожарки).
• Официант – это посредник, который принимает ваш заказ и относит на кухню. Вы не общаетесь напрямую с поварами.
• Кухня (бэкенд) – готовит блюдо по вашему заказу и отдаёт официанту.
• Официант приносит готовое блюдо – вы получаете результат.

Точно так же работает API:

• Фронтенд (клиент) – хочет получить данные, но не имеет прямого доступа к базе данных.
• API – описывает, какие запросы можно отправлять, в каком формате, что вернётся в ответ.
• HTTP-запрос – официант, который доставляет запрос на сервер.
• Бэкенд – обрабатывает запрос, обращается к базе данных, выполняет логику.
• HTTP-ответ – возвращает данные фронтенду в структурированном виде (обычно JSON).

Зачем нужен API?

• Разделение ответственности – фронтенд занимается отображением, бэкенд – логикой и данными. Каждый делает своё.
• Безопасность – фронтенд не имеет прямого доступа к базе данных. Всё через API, где можно контролировать права доступа.
• Универсальность – один API могут использовать разные клиенты: веб-сайт, мобильное приложение, другие сервисы.
• Обновления без простоя – можно обновить фронтенд или бэкенд независимо, если API остаётся неизменным.

Что такое REST?

REST (Representational State Transfer) – это архитектурный стиль для построения API. Это не протокол и не технология, а набор принципов, соглашений, как должен быть организован API.

REST API – самый популярный способ построения веб-API сегодня. Почему? Потому что он:

• Простой – легко понять и использовать
• Стандартизированный – работает поверх HTTP, который все знают
• Гибкий – подходит для любых задач
• Масштабируемый – легко добавлять новые функции

Основные принципы REST

1. Клиент-серверная архитектура

Клиент (фронтенд) и сервер (бэкенд) разделены. Клиент не знает, как устроен сервер внутри, а сервер не знает, как клиент отображает данные. Они общаются только через API.

2. Stateless (без сохранения состояния)

Каждый запрос от клиента к серверу должен содержать всю необходимую информацию. Сервер не помнит предыдущие запросы.

Пример:

Неправильно (с состоянием):

Запрос 1: "Авторизуй меня как Иван"
Запрос 2: "Покажи мои заказы" (сервер помнит, что ты Иван)

Правильно (без состояния):

Запрос 1: "Авторизуй меня как Иван" → получить токен
Запрос 2: "Покажи заказы пользователя с токеном XYZ123"

Каждый запрос самодостаточен. Это упрощает масштабирование – любой сервер может обработать любой запрос.

3. Кэшируемость

Ответы сервера должны явно указывать, можно ли их кэшировать (сохранять временно). Это ускоряет работу – повторные запросы берутся из кэша, а не идут на сервер.

4. Единообразный интерфейс

API должен быть последовательным и предсказуемым. Если один endpoint (точка входа) работает определённым образом, все остальные должны работать похоже.

5. Ресурсы и их представления

В REST всё вращается вокруг ресурсов. Ресурс – это любая сущность: пользователь, товар, заказ, статья.

Каждый ресурс имеет:

• Уникальный адрес (URI) – путь к ресурсу
• Представление – формат данных (обычно JSON)

Структура REST API: URL и методы HTTP

REST API строится на основе HTTP и использует его методы для операций с ресурсами.

HTTP-методы (глаголы)

• GET – получить данные (чтение)
• POST – создать новый ресурс
• PUT – полностью заменить существующий ресурс
• PATCH – частично обновить ресурс
• DELETE – удалить ресурс

Структура URL (endpoint)

URL в REST API обычно строится по схеме:

https://api.example.com/{коллекция}/{идентификатор}

Примеры:

• /users – коллекция всех пользователей
• /users/123 – конкретный пользователь с ID 123
• /products – все товары
• /products/456 – товар с ID 456
• /orders – все заказы
• /orders/789/items – позиции в заказе 789

CRUD-операции

CRUD – это аббревиатура основных операций с данными:

• Create – создать
• Read – прочитать
• Update – обновить
• Delete – удалить

REST API идеально подходит для CRUD:

Формат данных: JSON

REST API обычно использует JSON (JavaScript Object Notation) для передачи данных. Это текстовый формат, который легко читается и людьми, и машинами.

Пример JSON:

{
  "id": 123,
  "name": "Иван Иванов",
  "email": "ivan@example.com",
  "registered_at": "2024-01-15",
  "is_active": true,
  "orders_count": 5
}

JSON поддерживает:

• Объекты – { "key": "value" }
• Массивы – [ "item1", "item2" ]
• Строки – "текст"
• Числа – 123, 45.67
• Булевы значения – true, false
• Null – null

Примеры REST API-запросов

Давайте разберём конкретные примеры, как фронтенд общается с бэкендом через REST API.

Пример 1: Получить список товаров

Запрос (фронтенд отправляет):

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

Ответ (бэкенд возвращает):

HTTP/1.1 200 OK
Content-Type: application/json

{
  "products": [
    {
      "id": 101,
      "name": "Ноутбук Dell",
      "price": 50000,
      "in_stock": true
    },
    {
      "id": 102,
      "name": "Мышь Logitech",
      "price": 1500,
      "in_stock": true
    }
  ],
  "total": 2
}

Пример 2: Получить конкретный товар

Запрос:

GET /api/products/101 HTTP/1.1
Host: example.com

Ответ:

HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 101,
  "name": "Ноутбук Dell",
  "description": "15 дюймов, 16 ГБ RAM, 512 ГБ SSD",
  "price": 50000,
  "category": "Электроника",
  "in_stock": true,
  "quantity": 15
}

Пример 3: Создать нового пользователя (регистрация)

Запрос:

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

{
  "name": "Пётр Петров",
  "email": "petr@example.com",
  "password": "securepass123"
}

Ответ:

HTTP/1.1 201 Created
Content-Type: application/json
Location: /api/users/456

{
  "id": 456,
  "name": "Пётр Петров",
  "email": "petr@example.com",
  "created_at": "2024-11-22T10:30:00Z"
}

Код 201 Created означает, что ресурс успешно создан. Заголовок Location указывает URL нового ресурса.

Пример 4: Обновить данные пользователя

Запрос (изменить только email):

PATCH /api/users/456 HTTP/1.1
Host: example.com
Content-Type: application/json
Authorization: Bearer abc123token

{
  "email": "newemail@example.com"
}

Ответ:

HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 456,
  "name": "Пётр Петров",
  "email": "newemail@example.com",
  "updated_at": "2024-11-22T11:00:00Z"
}

Обратите внимание на заголовок Authorization – это токен авторизации. Без него сервер не позволит изменить данные пользователя.

Пример 5: Удалить товар из корзины

Запрос:

DELETE /api/cart/items/789 HTTP/1.1
Host: example.com
Authorization: Bearer abc123token

Ответ:

HTTP/1.1 204 No Content

Код 204 No Content означает успешное удаление. Тело ответа пустое – ничего возвращать не нужно.

Пример 6: Ошибка – товар не найден

Запрос:

GET /api/products/999999 HTTP/1.1
Host: example.com

Ответ:

HTTP/1.1 404 Not Found
Content-Type: application/json

{
  "error": "Product not found",
  "message": "Товар с ID 999999 не существует"
}

Коды статусов HTTP в REST API

REST API использует стандартные HTTP-коды для обозначения результата запроса:

2xx – Успех

• 200 OK – запрос выполнен успешно, вот данные
• 201 Created – ресурс успешно создан
• 204 No Content – успешно выполнено, но нечего возвращать (обычно DELETE)

3xx – Перенаправление

• 301 Moved Permanently – ресурс навсегда переехал на новый URL
• 304 Not Modified – данные не изменились, используй кэш

4xx – Ошибка клиента

• 400 Bad Request – неправильный формат запроса
• 401 Unauthorized – требуется авторизация
• 403 Forbidden – доступ запрещён (даже с авторизацией)
• 404 Not Found – ресурс не найден
• 409 Conflict – конфликт (например, email уже зарегистрирован)
• 422 Unprocessable Entity – данные не прошли валидацию

5xx – Ошибка сервера

• 500 Internal Server Error – что-то сломалось на сервере
• 502 Bad Gateway – проблема с промежуточным сервером
• 503 Service Unavailable – сервер временно недоступен

Авторизация в REST API

Не все данные должны быть доступны всем. Как сервер понимает, кто отправил запрос?

1. Токены (Token-based)

Самый популярный способ:

1. Пользователь авторизуется (логин + пароль)
2. Сервер возвращает токен (случайная строка, например: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...)
3. Фронтенд сохраняет токен (обычно в localStorage браузера)
4. Каждый последующий запрос отправляется с этим токеном в заголовке:

   Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

5. Сервер проверяет токен и понимает, кто это

2. JWT (JSON Web Token)

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

3. API Keys

Для сервисов, которыми пользуются другие приложения (не люди). Выдаётся постоянный ключ:

Authorization: ApiKey sk_live_1234567890abcdef

Pagination: работа с большими списками

Что если в базе 10 000 товаров? Вернуть их все сразу – медленно и нерационально. Используется пагинация (постраничный вывод).

Пример запроса:

GET /api/products?page=2&limit=20

Параметры:

• page=2 – вторая страница
• limit=20 – по 20 товаров на странице

Ответ:

{
  "products": [...20 товаров...],
  "page": 2,
  "limit": 20,
  "total": 10000,
  "pages": 500
}

Фильтрация и сортировка

Фильтрация:

GET /api/products?category=electronics&price_max=30000&in_stock=true

Вернёт товары из категории "Электроника" дешевле 30 000₽, которые есть в наличии.

Сортировка:

GET /api/products?sort=price&order=asc

Вернёт товары, отсортированные по цене по возрастанию.

REST API vs GraphQL vs gRPC

REST – не единственный способ построения API. Есть альтернативы:

GraphQL

Клиент запрашивает только те поля, которые нужны. Один endpoint вместо множества. Гибче, но сложнее.

gRPC

Бинарный протокол, очень быстрый. Используется для внутреннего общения между микросервисами. Для веба неудобен.

Для большинства веб-проектов REST остаётся оптимальным выбором: простой, понятный, проверенный временем.

Главное из статьи

• API – интерфейс для взаимодействия между программами
• REST – архитектурный стиль для построения API поверх HTTP
• Принципы REST: клиент-сервер, stateless, кэшируемость, единообразие, ресурсы
• HTTP-методы: GET (чтение), POST (создание), PUT/PATCH (обновление), DELETE (удаление)
• JSON – стандартный формат данных в REST API
• Коды статусов: 2xx – успех, 4xx – ошибка клиента, 5xx – ошибка сервера
• Авторизация – через токены (JWT) или API Keys
• Пагинация, фильтрация, сортировка – для работы с большими объёмами данных

Теперь у вас есть прочная теоретическая база: вы понимаете типы сайтов, фронтенд и бэкенд, клиент-серверную модель, базы данных и REST API. Это подготовка к практике – когда мы начнём разбирать реальные примеры, вы уже будете знать основы. Но даже в практических статьях мы продолжим углублять теорию, разбирая конкретные технологии и архитектурные решения.