Outlook REST API против Microsoft Graph

Question

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

1. Outlook REST API
2. Microsoft Graph

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

Answer 1

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

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

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

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

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