API Supply: Add the Result_count parameter to limit the number of results in the Batch questioning

Хочу предложить важное улучшение API для повышения производительности batch-запросов и экономии ресурсов.
ПРОБЛЕМА:

При использовании batch-запросов для поиска игр возникает серьезная проблема с производительностью:
Текущая ситуация:

• Запрос: /steam?game[]=730&game[]=440&game[]=570...
  (10 игр в batch)
• Ответ: 10 игр × 40 аккаунтов = 400 аккаунтов в JSON
• Размер JSON: большой
• Время парсинга: 2-3 минуты вместо секунд
• Трафик: огромный расход на каждый запрос

Результат: batch-запросы работают медленнее обычных запросов из-за огромного объема данных, хотя должны быть быстрее.
ПРЕДЛОЖЕНИЕ:

Добавить параметр
result_count
для ограничения количества возвращаемых результатов на каждую игру:
/steam?game[]=730&result_count=1 // Только 1 самый дешевый аккаунт
/steam?game[]=730&result_count=5 // Только 5 первых аккаунтов
/steam?game[]=730&result_count=10 // Только 10 аккаунтов

Альтернативные названия:
per_page
, max_results
, rows
(любое удобное для разработчиков)
ПРЕИМУЩЕСТВА:

Для пользователей API:

1. Скорость: JSON в 40 раз меньше → парсинг за секунды вместо минут
2. Экономия трафика: меньше данных = быстрее загрузка
3. Гибкость: каждый выбирает нужное количество результатов

Для сервера:

1. Производительность: меньше нагрузка при генерации ответа
2. Экономия ресурсов: меньше данных для обработки из БД
3. Пропускная способность: экономия трафика сервера
4. Быстрее ответы: меньше времени на формирование JSON

ПРИМЕРЫ ИСПОЛЬЗОВАНИЯ:

• Мониторинг цен: нужен только самый дешевый → result_count=1
• Анализ рынка: нужно 5-10 вариантов → result_count=10
• Сравнение продавцов: топ-3 предложения → result_count=3
• Полная выгрузка: без параметра → все как сейчас (обратная совместимость)

Совместимость:

• Обратная совместимость: без параметра работает как сейчас
• Простота: добавляется в существующие эндпоинты без изменения логики
  
  Параметр можно добавить во все игровые категории:
• /steam
• /fortnite
• /valorant
• /minecraft
• И другие разделы

АРГУМЕНТЫ В ПОЛЬЗУ:

1. Решает реальную проблему: многие разработчики сталкиваются с медленными batch-запросами
2. Гибкость: каждый использует по потребностям
3. Масштабируемость: снижает нагрузку при росте пользователей

Что думаете? Такое улучшение значительно повысит производительность API и удобство разработки!