Sport Line API — рекомендации по обновлению данных

Зачем нужно обновлять данные

Sport Line API работает через REST API. Каждый запрос возвращает актуальный на этот момент снимок данных.

Чтобы получать изменения счёта, периода, статистики и коэффициентов, приложение клиента должно повторять запросы с рекомендуемым интервалом.

Подключение через WebSocket находится в разработке и пока не используется в рабочей интеграции.

Данные или методы	Live	Prematch (`line`)
Полное меню: `menu`	не менее 20 секунд	не менее 60 секунд
Пошаговая навигация: `sports`, `countries`, `tournaments`	не менее 60 секунд	не менее 120 секунд
Список матчей: `events`	не менее 7 секунд	не менее 30 секунд
Конкретный матч: `event`	не менее 5 секунд	не менее 30 секунд
Топ-матчи: `topmatches`	не менее 30 секунд	не менее 120 секунд
Топ-матчи выбранного спорта: `toplist`	не используется	не менее 120 секунд

Меню и список матчей обновляются по-разному

Меню изменяется реже, чем счёты и коэффициенты. Поэтому не нужно запрашивать menu каждые 5 секунд.

Для обновления списка матчей используйте events. Для обновления подробных данных одного открытого матча используйте event.

Не запрашивайте event для каждого матча из events, если эти подробные данные не показываются пользователю. Это создаёт большое количество лишних запросов.

Не обновляйте таймер запросом каждую секунду

Не нужно запрашивать Sport Line API каждую секунду только для того, чтобы обновить таймер матча на экране.

Получите значение timer из API.
Обновляйте отображаемый таймер локально в интерфейсе.
При следующем плановом запросе синхронизируйте таймер с новым значением API.

При локальном обновлении учитывайте паузы, перерывы и остановки таймера, которые могут отличаться для разных видов спорта.

Жизненный цикл матча

Матч может перейти из prematch-линии в live-линию. При этом для live-матча формируется новый game_id, который не совпадает с game_id этого матча в prematch-линии.

Поэтому не следует связывать prematch- и live-матчи по game_id. Sport Line API не возвращает отдельный статус, по которому можно точно определить, что prematch-матч начался и был перенесён в live.

Когда матч больше недоступен в текущей линии, запрос event по его прежнему game_id может вернуть:

{
  "status": 1,
  "page": "/v1/event",
  "body": {
    "message": "Game id finished"
  }
}

Это сообщение не объясняет причину. Матч мог перейти в live с новым game_id, быть отменён или исчезнуть из линии по другой причине. Отдельные статусы для этих случаев API не возвращает.

Приложение должно:

Обновлять prematch- и live-данные отдельно.
Не связывать prematch- и live-матчи по game_id.
Получать актуальные live-матчи из метода events с типом live.
Прекращать запросы event по ID, для которого получено Game id finished.
Не определять по Game id finished, был ли матч начат, завершён или отменён.

Не допускайте наложения запросов

Если предыдущий запрос ещё не завершился, не запускайте второй запрос тех же данных.

Безопасный цикл обновления выглядит так:

отправить запрос
        ↓
дождаться ответа или ошибки
        ↓
обработать данные и обновить интерфейс
        ↓
выждать нужный интервал
        ↓
отправить следующий запрос

Такой подход не накапливает одновременные запросы, если API или сеть временно отвечает медленнее обычного.

Короткий чек-лист

Соблюдайте рекомендуемые интервалы для каждого метода.
Не запрашивайте меню чаще, чем список матчей.
Не запрашивайте подробный event для каждого матча.
Обновляйте prematch- и live-данные отдельно.
Не запускайте новый запрос, пока не завершился предыдущий.
При временных ошибках рекомендуется увеличивать паузу между повторами.
Прекращайте частое обновление завершённых матчей.

Следующий шаг: описание метода menu.