SharePoint REST API против Microsoft Graph API; какой подход рекомендуется? - PullRequest
Новая
       7

SharePoint REST API против Microsoft Graph API; какой подход рекомендуется?

0 голосов
/ 14 января 2020

Доступ к SharePoint Online можно получить либо с помощью собственного REST API SharePoint, либо с помощью Microsoft Graph API. Я кратко изучил оба API-интерфейса и вижу различия в возможностях. Например, в API-интерфейсе SharePoint есть вызовы методов типов функций (GetByTitle ()), тогда как API-интерфейс Graph, похоже, поддерживает доступ на основе идентификаторов или «путь к сайту». , Мое мнение таково, что SharePoint облегчает доступ к ресурсам с помощью «функции» в URL, однако я не уверен, что это RESTful. Было бы полезно узнать ваше мнение по этому аспекту.

Учитывая два варианта (SharePoint & Graph), который является рекомендуемым способом продвижения, учитывая следующие критерии:

  1. Будущее - с точки зрения улучшения, поддержка от Microsoft
  2. Производительность
  3. Функциональное покрытие - учитывая текущую версию Graph API

Кроме того, я не смог найти какие-либо рекомендации Microsoft по Это, если есть одна, пожалуйста, поделитесь ссылкой.

Спасибо.

Ответы [ 2 ]

1 голос
/ 14 января 2020

Я рекомендую Microsoft Graph API. Я знаю, что это прокси для реальных API Sharepoint, OneNote, Planner и т. Д. c, но то, как они улучшают график api изо дня в день, заставляет меня думать, что это будет продолжаться в течение хорошего времени. Допустим, если вы пишете приложение, которое хочет соединиться со многими конечными точками приложений Microsoft, достаточно одного класса, который обрабатывает все запросы API-графики, вместо того, чтобы искать определенные конечные точки приложений.

Производительность: я использовал Microsoft Graph API для большей части работы, связанной с SharePoint, и она работает хорошо и быстро. Я использую Graph Explorer, чтобы проверить график, если он действительно работает, прежде чем внедрять его в приложение.

Охват функциональности: Очевидно, что граф является прокси реального API, поэтому он не будет охватывать все процессы, которые вам нужны делать в SharePoint. Например, мне пришлось создать группу Sharepoint Group, которую я не смог найти с помощью графа api. Но я полагаю, что по мере того, как все больше людей голосуют по этим запросам, график API также предоставляет эти новые возможные конечные точки прокси. Но опять же, если ваше приложение работает только с Sharepoint, то я считаю, что я бы придерживался SharePoint API. В пользу Graph API у них также есть то, что называется дельта-запросом и уведомлением о подписке, чтобы увидеть изменения в файлах и документах.

0 голосов
/ 05 марта 2020

У меня сложилось впечатление, что Graph API предназначен для централизации, создания одной конечной точки для подключения ко всем службам Sharepoint через API. Имея это в виду, я задаюсь вопросом, не стоит ли нам спрашивать, какой вариант лучше, а стоит спросить, когда так называемый нативный вариант закончится. График является более перспективным в том смысле, что это направление, в котором движется MS. Я не могу говорить с выступлением лично. Что касается функциональности, я не могу представить, чтобы Graph был функционально хуже , чем предыдущие итерации SP. Это может быть функционально другим. Но это должно расширить функциональность API.

...