Перспектива REST API против Microsoft Graph

Question

Я работаю над приложением, которое необходимо для извлечения и редактирования событий календаря из Outlook.com и офис 365. Я видел есть 2 вариант:

1. Перспектива REST API
2. Microsoft Graph

У них, похоже, практически такой же интерфейс. Я видел, что API-интерфейс Outlook REST поддерживает уведомления (webhooks), на графике Microsoft нет? Итак, какой из них выбрать, каковы преимущества/недостатки и почему существуют 2 api?

Answer 1

Чтобы получать и редактировать события календаря с Outlook.com, работают API-интерфейсы Microsoft Graph API и Outlook REST. Если вам требуется Webhooks для приложения, которое вы планируете использовать в процессе производства, вам необходимо использовать конечную точку Outlook REST API версии 2.0. У нас есть веб-камеры, доступные в предварительном просмотре на графике Microsoft, и работают над ними, поэтому вы можете использовать их в своих производственных приложениях в будущем. Если вам не нужны Webhook для вашего приложения, вы можете использовать Microsoft Graph v1.0. Терминалы Microsoft Graph и Outlook REST API полностью поддерживаются.

Теперь о том, почему существует 2 конечных точки. Outlook REST API v1.0 был запущен в октябре 2014 года, и мы предложили улучшенную версию версии 2.0 в ноябре 2015 года. Он имеет самые последние самые большие функции Outlook, открытые через API. Microsoft Graph v1.0 - это удобная конечная точка, которую мы начали в ноябре 2015 года для приложения для доступа к информации из нескольких служб Microsoft, например Outlook, One Drive и Azure Active Directory. Фактически, когда вы отправляете запрос на конечную точку Microsoft Graph v1.0 для любых функций Outlook, запрос маршрутизируется в конечную точку Outlook REST API версии 2.0 под обложками. Таким образом, комплекты API одинаковы по дизайну!

Мы прилагаем все усилия, чтобы закрыть любые промежутки между конечными точками API для конечных пользователей (API-интерфейсы Outlook REST, API OneDrive, API AAD Graph и т. Д.) И Microsoft Graph, но будет небольшая дельта по двум причинам.

1. Индивидуальные услуги могут иметь объекты, имеющие одно и то же имя, но означающие нечто иное. Например, как Outlook, так и OneDrive имеют «папку», но они означают разные вещи. В этом случае нам необходимо рационализировать схему API Microsoft Graph, чтобы дать вам понять, к какому объекту вы обращаетесь при просмотре Microsoft Graph API. Папка была доступна в конечной точке Outlook API версии 1.0, и мы переименовали ее в MailFolder в конечной точке Outlook API версии 2.0, и она также была показана через Microsoft Graph API версии 1.0. Таким образом, вы можете всегда видеть некоторые функции или API-интерфейсы, открытые в отдельной конечной точке службы, в течение некоторого времени до того, как одна и та же функция или API открывается через Microsoft Graph.
2. Некоторые горизонтальные возможности, например, Webhooks могут быть доступны в Preview или GA ранее в конечной точке службы до того, как они будут доступны в Microsoft Graph. Это связано с тем, что Microsoft Graph API является более новой конечной точкой по сравнению с отдельными конечными точками обслуживания. Со временем этот список пробелов, как ожидается, снизится до нуля.

Наша рекомендация - использовать Microsoft Graph, если у вас есть функции/API, необходимые для поддержки ваших производственных приложений или, по крайней мере, в режиме предварительного просмотра для поддержки разработки приложений. Это упростит вам в будущем расширение функциональности вашего приложения, требующее доступа к нескольким службам Microsoft, без изменения конечных точек. Вы можете использовать отдельные конечные точки службы, такие как API REST Outlook, если вам нужна функция, доступная только в отдельной конечной точке службы, либо в производстве (v2.0), либо в виде предварительного просмотра (бета).