Пагинация не дает результатов в Google Fit - PullRequest
Новая
       17

Пагинация не дает результатов в Google Fit

0 голосов
/ 01 ноября 2018

Я использую REST API Google Fit. Я хочу перечислить сессии с помощью метода fitness.users.sessions.list. Это дает мне несколько десятков результатов.

Теперь я хотел бы получить больше результатов, и для этого я установил для pageToken значение, которое я получил из предыдущего ответа. Но новые результаты не содержат каких-либо точек данных, просто еще одна страница Token: 

{
 "session": [
 ],
 "deletedSession": [
 ],
 "nextPageToken": "1541027616563"
}

То же самое происходит, когда я использую функцию разбивки на страницы Google Python API Client: я итерирую результаты, но никогда не получаю никаких новых данных. 

    request = self.service.users().sessions().list(userId='me')
    while request is not None:
        response = request.execute()
        for ds in response['session']:
            yield ds
        request = self.service.users().sessions().list_next(request, response)

Я уверен, что в Google Fit гораздо больше (!) Данных о сеансе для моей учетной записи. Я что-то упускаю из-за нумерации страниц?

Спасибо

Ответы [ 2 ]

0 голосов
/ 04 ноября 2018

Я думаю, что описание параметра pageToken на самом деле довольно запутанно в документации ( этот ответ был написан до обновления документации ).

Токен продолжения, который используется для просмотра больших наборов результатов. Чтобы получить следующую страницу результатов, установите для этого параметра значение nextPageToken из предыдущего ответа.

Это объединяет два понятия: продолжение и пейджинг. На самом деле в реализации Users.sessions.

нет никакой подкачки.

Сессии индексируются по метке времени их изменения. Существует два (или три, в зависимости от того, как вы считаете) способа взаимодействия с API:

  • Передать время начала и / или окончания. Опущенное время начала и окончания принимается за начало и конец времени соответственно. В этом случае вы вернетесь ко всем сеансам, приходящимся на эти промежутки времени.
  • Не передавать ни время начала, ни время окончания. В этом случае вы будете получать все сеансы между прошлым и настоящим. Это время:
    • pageToken, если предусмотрено
    • В противном случае, это 7 дней назад (на самом деле это не указано в документации, но это поведение)

В любом из этих случаев вы получаете обратно nextPageToken, что сразу после самого последнего сеанса в результатах. Таким образом, nextPageToken действительно является токеном продолжения , потому что он говорит о том, что вам сообщили обо всех сеансах, измененных до сих пор: передайте этот токен обратно, чтобы сообщить обо всем, что было изменено между nextPageToken и «текущее время» для получения обновлений.

Таким образом, если вы выдадите запрос, который выбирает все сеансы за последние 7 дней (без времени начала / окончания, без маркера страницы) и получите nextPageToken, вы получите только что-то обратно в запросе, используя этот nextPageToken если какие-либо сеансы были изменены между первым и вторым запросами.

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

С точки зрения действительности startTime, который вы передали в своем комментарии , это ошибка. RFC3339 определяет, что доли секунды должны быть необязательными.

Я посмотрю, как исправить это; но между тем, просто убедитесь, что вы пропустили дробное количество секунд (даже если это всего лишь .0, например, 2018-10-18T00:00:00.0+00:00).

0 голосов
/ 02 ноября 2018

Возможно, причина в том, что формат используемого вами URL отличается от примера в документации .

Вы используете: 

startTime=2018-10-18T00:00:00+00:00

В котором в документации указано: 

startTime=2014-04-01T00:00:00.00Z

В документации также указано, что требуются параметры запроса startTime и endTime.

...