Блог

Посмотрев видео Microsoft на этой странице, я решил, что мне следует начать тестирование разбиения на страницы на стороне сервера, отыскав поля @odata.nextLink во всех моих ответах на запросы Graph API (v1.0), особенно на ресурсах SharePoint. В видео примерно в 1:38 один из докладчиков говорит, что следующая ссылка «обычно» размещается рядом с коллекцией в ответе.

До сих пор это то, с чем я столкнулся, когда анализировал ответ json на запросы: поле коллекции помещается сразу после поля @odata.nextLink в объекте json. В приведенном ниже примере поле коллекции «значение» сразу следует за полем «@odata.nextLink».

Однако меня немного беспокоит выбор слов докладчиками («обычно»). Могу ли я ожидать, что это всегда будет так, хотя и с Graph API?

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

Спасибо.

Вы никогда не должны предполагать фиксированный порядок в любом сериализованном ответе. В случае OData a nextLink всегда будет свойством верхнего уровня, но оно может отображаться выше или ниже возвращаемой коллекции:

Все аннотации или управляющая информация для структурного или навигационного свойства ДОЛЖНЫ отображаться в виде группы непосредственно перед самим свойством. Единственным исключением является nextlink коллекция, которая МОЖЕТ появиться после коллекции, которую она аннотирует.

Также стоит отметить, что, хотя другие аннотации всегда появляются перед коллекцией, спецификация не определяет порядок этих аннотаций (за некоторыми исключениями, такими как id и etag ).

При работе с JSON свойства лучше всего извлекать по имени (обычно путем десериализации ответа).