Batching requests

Batching Requests в REST API

📚 27 вопросовПройти тест →
Лекция

Batching Requests в REST API

Batching requests

Batching Requests в REST API

Введение: одна поездка вместо пяти 🚚

Batching — это как объединить несколько доставок в одну машину.
Если каждый запрос ездит отдельно, растут задержки и нагрузка.
💡 Совет: группируйте запросы, когда клиенту нужно много данных сразу.
✅ Вывод: batching уменьшает сетевые «поездки» и делает API быстрее для клиента.

Проблема → решение

Проблема: клиент делает 5–10 запросов подряд, страница грузится медленно, сеть перегружена.
Решение: один batch‑запрос, где сервер обрабатывает несколько операций за раз.
✅ Вывод: batching снижает latency и количество запросов.

Чем помогает и как работает

Batching помогает:
  • уменьшить количество сетевых вызовов;
  • ускорить загрузку сложных экранов;
  • снизить нагрузку на API‑шлюз.
Как это работает:
  1. Клиент собирает несколько операций в один payload.
  2. Отправляет POST на batch‑endpoint.
  3. Сервер выполняет операции по очереди или параллельно.
  4. Возвращает массив результатов с кодами для каждого под‑запроса.
  5. Клиент использует ответы без повторных вызовов.
✅ Вывод: batch — это «контейнер» для нескольких запросов.

Ключевые термины (простыми словами)

  • Batching (пакетирование) — несколько запросов в одном HTTP‑вызове.
  • Batch endpoint — специальный URL, принимающий пачку операций.
  • Sub‑request (под‑запрос) — одна операция внутри batch.
  • Partial success (частичный успех) — часть операций успешна, часть — нет.
  • Correlation id — идентификатор, чтобы связать ответ с запросом.

Самое важное (must‑know)

  • Batch не означает «атомарность» — возможен частичный успех.
  • Каждый под‑запрос должен иметь свой id.
  • В ответе обязателен статус для каждого под‑запроса.
  • Лимитируйте размер batch (количество и вес).
  • Для повторов используйте идемпотентность.

1. Batch endpoint — точка входа

Назначение: принять несколько операций одним запросом.
Простыми словами: один адрес для группы действий.
Аналогия: окно «одним пакетом» в банке.
Пример:
POST /batchContent-Type: application/json {  "requests": [    { "id": "u1", "method": "GET", "path": "/users/1" },    { "id": "o1", "method": "GET", "path": "/orders/5" }  ]}
🔎 Как это происходит на практике:
  1. Клиент формирует массив запросов.
  2. Сервер принимает пакет и валидирует формат.
  3. Сервер выполняет операции и готовит ответ.
Характеристики:
  • ✅ один HTTP‑вызов вместо многих;
  • ✅ единый формат;
  • ✅ удобно для сложных экранов.
Когда использовать: когда нужны данные из нескольких источников сразу.
✅ Вывод: batch‑endpoint снижает число запросов.

2. Формат ответа — частичный успех

Назначение: вернуть результат по каждому под‑запросу.
Простыми словами: каждый запрос получает свой ответ.
Аналогия: чек с позицией и статусом для каждого товара.
Пример:
{  "responses": [    { "id": "u1", "status": 200, "body": { "id": 1 } },    { "id": "o1", "status": 404, "body": { "error": "Not found" } }  ]}
🔎 Как это происходит на практике:
  1. Сервер сопоставляет ответ с id.
  2. Каждый под‑запрос имеет свой статус.
  3. Клиент обрабатывает успех и ошибки отдельно.
Характеристики:
  • ✅ поддерживает частичные ошибки;
  • ✅ понятная диагностика;
  • ✅ стабильная связь запрос↔ответ.
Когда использовать: всегда при batch‑ответе.
✅ Вывод: batch‑ответ — это массив результатов.

3. Идемпотентность и повторы

Назначение: безопасно повторять запросы.
Простыми словами: повтор не должен создавать дубли.
Аналогия: повторная оплата без второго списания.
Пример:
POST /batchIdempotency-Key: 8f1a-44c2
🔎 Как это происходит на практике:
  1. Клиент добавляет idempotency‑key для batch или под‑запросов.
  2. Сервер сохраняет результат выполнения.
  3. Повтор возвращает тот же ответ.
Характеристики:
  • ✅ защищает от дублей;
  • ✅ упрощает ретраи;
  • ✅ критично для create‑операций.
Когда использовать: при возможных повторах и таймаутах.
✅ Вывод: без идемпотентности batch опасен.

4. Лимиты и валидация

Назначение: защитить сервер от больших пачек.
Простыми словами: нельзя отправлять «мешок» без ограничений.
Аналогия: лимит веса в почтовом отделении.
Пример:
Максимум: 20 под‑запросов, 1 MB payload
🔎 Как это происходит на практике:
  1. Сервер проверяет размер и количество.
  2. Слишком большой batch отклоняется.
  3. Клиент получает понятную ошибку (например, 413).
Характеристики:
  • ✅ снижает риск перегрузки;
  • ✅ защищает от злоупотреблений;
  • ✅ делает поведение предсказуемым.
Когда использовать: всегда для публичных API.
✅ Вывод: лимиты — обязательная защита.

5. Когда batching не нужен

Назначение: не ухудшать UX там, где нужен real‑time.
Простыми словами: иногда лучше отправить один быстрый запрос.
Аналогия: не ждать автобус, если нужно срочно.
Пример:
Чат, стриминг, лайв‑обновления — без batching
🔎 Как это происходит на практике:
  1. Если нужен моментальный ответ — не batch.
  2. Для стриминга и real‑time используют отдельные каналы.
  3. Batch применяют для «пачки» независимых данных.
Характеристики:
  • ✅ улучшает UX;
  • ✅ избегает лишней задержки;
  • ✅ сохраняет простоту API.
Когда использовать: UI‑сценарии с мгновенной реакцией.
✅ Вывод: batching — не универсальный инструмент.

Сравнение: Batching vs Bulk

ПодходЧто делаетПример
Batchingнесколько разных запросовGET /users + GET /orders
Bulkодна операция над многимиPATCH /users (100 шт)

Сравнение: Batching vs параллельные запросы

ПодходПлюсыМинусы
Параллельпроще на серверемного сетевых вызовов
Batchingменьше запросовсложнее обработка

Типичные ошибки

Ошибка 1: Один общий статус на весь batch

❌ Неправильно: 200 «для всех».
✅ Правильно: статус для каждого под‑запроса.
Почему: операции могут завершиться по‑разному.

Ошибка 2: Нет id у под‑запросов

❌ Неправильно: ответы без сопоставления.
✅ Правильно: каждому запросу — свой id.
Почему: клиент должен связать ответ с запросом.

Ошибка 3: Нет лимитов

❌ Неправильно: unlimited batch.
✅ Правильно: лимит размера и количества.
Почему: защита от перегрузки.

Ошибка 4: Ретраи без идемпотентности

❌ Неправильно: повтор create без защиты.
✅ Правильно: idempotency‑key.
Почему: иначе появятся дубли.

Ошибка 5: Batch для real‑time сценариев

❌ Неправильно: батчить чат.
✅ Правильно: отдельные быстрые запросы/стриминг.
Почему: batching добавляет задержку.

Ошибка 6: Ссылки на документацию вместо ссылок в ответе

❌ Неправильно: клиент «угадывает» next шаг.
✅ Правильно: отдавать нужные данные в ответе.
Почему: клиент должен работать без хардкода.

Best Practices

  • Используйте requests[] и responses[].
  • Каждому под‑запросу — свой id.
  • Отдавайте статус на каждый элемент.
  • Лимитируйте размер batch.
  • Добавляйте idempotency‑key для повторов.
  • Используйте batch только там, где это ускоряет UX.

Часто спрашивают на собеседованиях

  • В чём разница batching и bulk?
  • Зачем нужен per‑item status?
  • Как обрабатывать частичный успех?
  • Почему нужен idempotency‑key?
  • Когда batching вреден?
✅ Вывод: после лекции понятно, как проектировать batch‑endpoint и ответы.

Заключение

Batching — это способ сократить количество запросов и сделать API быстрее.
✅ Вывод: применяйте batching там, где есть пачка независимых операций.
🎯

Проверьте знания

Закрепите материал — пройдите тест по теме «Batching requests»

Пройти тест →