Pagination hardening

Ограничение глубины и прозрачности пагинации — дешёвый способ затруднить массовую выгрузку данных через публичный API.

Техники

Лимит записей за запрос

Жёсткий максимум на limit/page_size, даже если клиент просит больше:

GET /api/rides?limit=1000 → сервер отдаёт максимум 50

Игнорировать клиентский limit выше порога — не ошибку, а тихо обрезать.

Ограничение offset для неавторизованных

Публичные запросы (без сессии): offset максимум 500 (10 страниц по 50). Авторизованные — без ограничений.

offset = Math.min(requestedOffset, user ? Infinity : MAX_PUBLIC_OFFSET)

Скрапер без аккаунта не может пройти дальше 10-й страницы. С аккаунтом — может, но привязан к сессии (легче отследить и забанить).

Скрытие total_count

Не отдавать общее количество записей в ответе:

// Плохо — скрапер знает объём данных
{ "total": 15420, "items": [...] }
 
// Хорошо — скрапер не знает, сколько осталось
{ "has_more": true, "items": [...] }

Без total_count скрапер не может оценить прогресс и спланировать параллельные запросы.

Cursor-based pagination

Вместо offset — опакный курсор (encrypted token):

// Offset-based (легко скрапить)
GET /api/rides?offset=100&limit=50
 
// Cursor-based (сложнее)
GET /api/rides?cursor=eyJpZCI6MTAwfQ&limit=50

Преимущества:

• Нельзя запросить произвольную страницу — только «следующая»
• Параллельный скрейпинг невозможен (каждый курсор зависит от предыдущего)
• Стабильнее при insert/delete (offset сдвигается, cursor — нет)

Дифференцированные лимиты

Суть: доверие пропорционально идентификации. Анонимный запрос — минимум возможностей.

Комбинация с rate limiting

Pagination hardening и rate limiting работают вместе:

• Rate limit ограничивает скорость запросов
• Pagination hardening ограничивает объём данных за один запрос
• Вместе: скрапер ограничен и по скорости, и по глубине

Связанные заметки

• Защита API от скрейпинга — общая стратегия
• HMAC-подпись API запросов — дополнительная защита запросов