Когда мы получаем списки через API, то получать весь миллион записей сразу - плохая идея. Лучше получать по частям — порциями.
Пагинация — отвечает за порционное получение данных в REST API.
Помогает:
✔️ не перегружать как сервер, так и клиента API;
✔️ ускорить отклик на запрос;
✔️ пользователю не надо ждать данных вечность.
👇 6 способов пагинации на примере получения списка пользователей:
🔹 Offset
Используются параметры смещения (offset) и ограничения (limit) для определения начальной точки и количества возвращаемых записей.
GET /users?offset=0&limit=3
✅ Простая в реализации
✅ Подходит, когда данных немного
➖ Неэффективна при больших offset: система перебирает все записи, чтобы дойти до нужных
🔹 Page
Используются номер и размер каждой страницы для переключения между ними.
GET /users?page=2&size=10
✅ Привычно для пользователей (страницы)
✅ Подходит, когда пользователь реально листает страницы
➖ Проблемы те же, что у offset
🔹 Cursor
Используется курсор (id записей в БД) для обозначения позиции в наборе данных.
GET /users?cursor=123
✅ Быстрая и надёжная при больших объёмах данных.
✅ Часто используют в соцсетях, чатах и платежных системах из-за постоянного потока новых данных.
🔹 Keyset
Используется ключ для фильтрации набора данных. Часто это первичный ключ или другой индексированный столбец.
GET /users?afterId=123&limit=3
✅ Быстрая при больших данных
✅ Подходит для бесконечной прокрутки (infinite scroll)
➖ Требует уникального и индексированного поля (обычно ID)
🔹 Time
Используются временные метки или дата для разбиения записей на страницы.
GET /users?startTime=...&endTime=...
✅ Идеальна для систем, где данные привязаны ко времени: логи, события, аналитика
🔹 Гибридная пагинация
Этот метод объединяет несколько методов пагинации, чтобы максимально использовать их сильные стороны.
Поддерживается сразу несколько способов из перечисленных выше
➖ Чуть сложнее реализовать
➖ Может путать клиентов API
#RestApiGA