Microsoft Graph чи старі REST-кінцеві точки: посібник з прийняття рішень до 2026 року

Питання трохи неправильне

Кожен, хто під’єднує додаток до Microsoft 365, Entra ID, Teams чи Outlook, рано чи пізно шукає відповідь на запитання типу «REST API чи Microsoft Graph?». Це звучить як справедливий вибір між двома варіантами, але насправді це не зовсім так. Сам Microsoft Graph є REST API. Люди зазвичай мають на увазі наступне:

Чи варто продовжувати використовувати старіші REST-кінцеві точки для кожного сервісу окремо (Azure AD Graph, Outlook REST API, SharePoint REST, EWS тощо), чи перейти на єдиний Microsoft Graph API?

У 2026 році до цього питання додаються чіткі терміни. Microsoft витратила приблизно три роки на закриття фрагментованих API та спрямування всіх користувачів до Graph, причому деякі з цих закриттів відбудуться вже через кілька тижнів. Нижче ви знайдете систематизований перелік назв, інформацію про статус того, що все ще працює, порівняння та процес прийняття рішень, який можна застосовувати як до нових версій, так і до старих інтеграцій.

Систематизація назв

REST — це архітектурний стиль. Це не продукт, який потрібно встановлювати. API, яке використовує HTTP-дії типу GET, POST, PATCH та DELETE, адресує об’єкти через URL як ресурси та зазвичай обмінюється даними у форматі JSON, може справедливо називатися RESTful. За цим визначенням Microsoft Graph, Azure AD Graph, вже не використовуваний Outlook REST API та SharePoint REST також підходять під цю категорію.

Microsoft Graph – це єдиний REST API, який охоплює як Microsoft 365, так і Entra ID. Вам не потрібно перемикатися між різними кінцевими точками для електронної пошти, файлів та даних каталогів. Усе знаходиться під адресою https://graph.microsoft.com/: користувачі, групи, електронна пошта, календарі, чати в Teams, файли, попередження про безпеку, а також штучні інтелектуальні агенти.

Тож корисним є порівняння єдиного Graph із старими, специфічними для кожного сервісу REST-інтерфейсами. Те, на якому етапі знаходяться ці старі API, має велике значення, адже ситуація стрімко змінилася протягом останнього року.

Що все ще працює у 2026 році

Якщо щось із вашого майна все ще підключається до graph.windows.net, ви вже запізнилися; починаючи з середини липня 2026 року цей варіант буде недоступний протягом кількох тижнів. Старий REST API Outlook вже не існує більше двох років. Доступ сторонніх програм до Exchange Online через EWS буде припинений цієї осені. Майже кожен аргумент, який колись виправдовував використання нативних REST-кінцевих точок, або вже втратив силу, або ось-ось її втратить.

Microsoft вже кілька разів змінювала ці терміни, тому перевірте поточні дедлайни на сайті Microsoft Learn перед тим, як планувати міграцію. Проте напрямок розвитку залишається незмінним вже багато років: усе консолідується навколо Graph.

Graph проти старих кінцевих точок

У повсякденній роботі найважливішими є три відмінності.

Аутентифікація

Протягом понад десяти років ця система накопичила безліч варіантів автентифікації: Basic Auth, NTLM, Kerberos та Azure Access Control Service, від якого залежали додатки SharePoint. Для робочих навантажень Microsoft 365 усі вони були відмінені. Graph завжди підтримував лише OAuth 2.0 через Microsoft Entra ID. Це забезпечує один спосіб отримання токенів, одну модель дозволів та одне місце для перевірки того, хто може отримати доступ до чого. Це покращує безпеку для адміністраторів, а не лише надає розробникам кращий API.

Запити та групування

Один запит до Graph, як показано нижче, може фільтрувати, обробляти та формувати сторінки електронної пошти протягом однієї поїздки:

GET https://graph.microsoft.com/v1.0/me/messages
    ?$select=subject,receivedDateTime,from
    &$filter=receivedDateTime ge 2026-07-01T00:00:00Z
    &$top=25
    &$orderby=receivedDateTime desc

У порівнянні зі старішими, менш гнучкими кінцевими точками для досягнення того самого результату часто потрібно було кілька обмежених запитів або фільтрації на клієнті. Якщо додати $batch, можна об’єднати до 20 незалежних операцій у один HTTP-запит, поєднуючи операції читання та запису для абсолютно різних типів ресурсів.

Обмеження швидкості

Graph застосовує кілька обмежень одночасно: за додатком серед усіх орендарів, за орендарем серед усіх додатків та за додатком всередині одного орендаря. Конкретні цифри відрізняються залежно від сервісу – пошта, файли, каталоги та месенджер Teams мають свої власні ліміти. Як тільки буде досягнутий перший ліміт, повертається код 429 Too Many Requests разом із заголовком Retry-After, який вказує, скільки часу потрібно чекати. Порівняно зі старими API, де обмеження часто не були задокументовані та їх доводилося з’ясовувати вже під час роботи, це значний крок вперед. Порада залишається актуальною: використовуйте $select, щоб отримувати лише необхідні поля, віддавайте перевагу пакетним та дельта-запитам замість постійного опитування, та завжди дотримуйтесь значення Retry-After, а не негайно повторюйте спробу.

Де ще має сенс використовувати щось інше, окрім Graph

Graph ще не охоплює все, і деякі випадки справді вимагають використання іншого API.

• Детальне керування сайтом SharePoint. Повна інформація про рівні дозволів, деякі операції з групами сайтів, а також частина функцій керування типами контенту та схемами списків доступні лише у SharePoint REST під адресою _api/web/.... У зрілих проектах SharePoint щоденна робота з файлами, списками та дисками зазвичай виконується за допомогою Graph, а SharePoint REST використовується лише для тих функцій, яких бракує.
• Веб-частини SPFx. Середовище виконання SharePoint Framework вже забезпечує готовий контекст SharePoint REST, тому для налаштувань всередині сторінки це часто найпростіший спосіб, хоча та сама веб-частина також може використовувати Graph.

Exchange Server на місці. Обмеження, введені у жовтні 2026 року, стосуються лише Exchange Online, тому EWS продовжує функціонувати з Exchange на місці. Для повноцінної налагодженої системи електронної пошти справжнім вибором є або EWS, або міграція спочатку до Exchange Online.

Великі одноразові завдання адміністрування. Масове очищення дозволів, підготовка звітів для користувачів та налаштування сайтів у великих масштабах часто виконуються за допомогою інструментів вищого рівня, таких як PnP PowerShell, який у свою чергу внутрішньо використовує Graph та SharePoint REST.

Окрім цих вузьких випадків, у цьому році немає значних технічних причин для початку абсолютно нового проекту з використанням старих кінцевих точок для кожного сервісу, оскільки більшість з них вже не працюють або перебувають на шляху до виходу з експлуатації.

Як прийняти рішення

Оцініть будь-яку нову інтеграцію за допомогою цих запитань:

1. Чи це нова версія? Використовуйте Microsoft Graph. Нові функції спочатку з’являються саме там, і це єдиний інструмент, у який Microsoft все ще інвестує.
2. Чи використовує існуюче додаток Azure AD Graph, Outlook REST API чи додатки SharePoint на основі ACS? Outlook REST та ACS вже вийшли з етапу підтримки, а Azure AD Graph припинить роботу 31 липня 2026 року. Вважайте це терміновим завданням.
3. Чи використовує сторонній додаток EWS для роботи з Exchange Online? Microsoft почне блокувати такі запити 1 жовтня 2026 року. Почніть переходити на кінцеві точки пошти та календаря Graph вже зараз.
4. Чи потрібна вам функція SharePoint, якої ще немає у Graph? Для цього запиту використовуйте SharePoint REST, а для всього іншого — Graph. Спочатку ознайомтесь з документацією SharePoint-in-Graph, адже список відсутніх функцій постійно скорочується.

Чи є середовище лише локальним? EWS та інші протоколи локального середовища все ще є дійсними там. Microsoft Graph орієнтований на хмару та не може безпосередньо підключатися до локальних серверів Exchange чи SharePoint.

Для майже всіх це зводиться до одного правила: використовуйте Microsoft Graph, якщо у вас немає конкретної, задокументованої причини не робити цього.

Та сама заявка тоді та зараз

Ось вже не використовуваний варіант виклику Outlook REST v2.0, показаний лише для порівняння:

GET https://outlook.office.com/api/v2.0/me/messages
Authorization: Bearer {token}

Цей кінцевий пункт відповідає з кодом HTTP 410 Gone з березня 2024 року. Версія запиту у форматі Graph виглядає так:

GET https://graph.microsoft.com/v1.0/me/messages?$select=subject,from,receivedDateTime&$top=10
Authorization: Bearer {token}

SharePoint REST, який все ще підтримується, читає елементи списку наступним чином:

GET https://{tenant}.sharepoint.com/sites/{site}/_api/web/lists/getbytitle('Documents')/items
Authorization: Bearer {token}
Accept: application/json;odata=verbose

Там, де Graph підтримує ту саму операцію, виклик виглядає так:

GET https://graph.microsoft.com/v1.0/sites/{site-id}/lists/{list-id}/items
Authorization: Bearer {token}

Механізми HTTP залишаються ідентичними в обох епохах. Graph додає одну базову URL, одну модель автентифікації та одну конвенцію JSON, незалежно від того, з яким саме сервісом Microsoft 365 ви спілкуєтесь.

Міграція зі старої API

Якщо ви щойно усвідомили, що щось у вашому тенанті все ще залежить від API, яке виходить з експлуатації, ознайомтесь із цим списком:

1. Дізнайтеся, що насправді її використовує. Entra пропонує дві рекомендації — „Мігрувати додатки“ та „Мігрувати сервісні принципали“, які перераховують реальне використання Azure AD Graph у вашому тенанті протягом останніх 30 днів. Це значно краще, ніж здогадуватися на основі коду джерела.
2. Чітко відстежуйте дозволи. Старі дозволи не перетворюються один до одного у діапазони Graph. Користуйтеся офіційними довідниками Microsoft щодо відповідності дозволів, замість того, щоб припускати, що два діапазони з схожими назвами є еквівалентними.
3. Перенесіть автентифікацію до MSAL. Усе, що все ще використовує стару бібліотеку автентифікації Azure AD (ADAL), потребує окремої, вже затриманої міграції, адже підтримка ADAL припинилася багато років тому.
4. Змініть SDK, а не лише URL. Офіційні Graph SDK для .NET, JavaScript та TypeScript, Python, Java, Go та PowerShell самостійно керують групуванням запитів, повторними спробами та сторінкуванням. Не пишіть власноруч базові HTTP-запити, якщо це справді не необхідно.
5. Будьте обережні з бета-версіями. Якщо певна функція доступна лише через кінцеву точку beta Graph, її інтерфейс може змінитися без попередження. Або плануйте це, або чекайте, поки вона стане загальнодоступною.
6. Виявляйте помилки 429 у тестовому середовищі. Проводьте тестування навантаження з реалістичним обсягом запитів, щоб ви досягли межі обмежень раніше, ніж це зроблять ваші користувачі.
7. Введіть справжню дату закінчення у свій календар та перевірте її за актуальною документацією від Microsoft безпосередньо перед тим, як покладатися на неї. Ці дати вже змінювалися раніше, тому будь-яку дату, отриману з інших джерел, включаючи цю сторінку, слід вважати тимчасовою.

Graph — це також місце керування агентами ШІ

Є ще одна причина, чому ця прогалина продовжує зростати. Graph перетворюється на платформу керування екосистемою агентів ШІ від Microsoft. У 2026 році Microsoft додала кінцеві точки Graph для керування агентами та додатками Microsoft 365 Copilot, ведення інвентарю агентів та отримання більш детальних звітів про використання Copilot, а також функцій, пов’язаних із новішими ліцензіями, такими як Agent 365. У Azure AD Graph, Outlook REST чи EWS цього немає, і ніколи не буде. Якщо ваша організація планує розробляти розширення для Copilot чи власні агенти, це ще один шлях, який веде лише до Graph.

Яке рішення ви отримуєте

На запитання, яке поставлено у заголовку, у 2026 році існує досить чітка відповідь:

• Починати щось нове в Microsoft 365 чи Entra ID? Використовуйте Microsoft Graph. Більше немає ситуацій, коли новий проект мав би розпочинатися за допомогою специфічного REST API старого сервісу.
• Підтримувати стару інтеграцію? Порівняйте її з таблицею статусів вище. Якщо вона використовує Azure AD Graph, Outlook REST, додатки SharePoint на основі ACS чи доступ EWS від сторонніх постачальників, у вас є терміни, і деякі з них вже дуже близькі.
• У Graph відсутня певна функція SharePoint? Для цього окремого виклику використовуйте SharePoint REST, а все інше залиште в Graph.

У 2018 році, коли Microsoft справді використовував кілька конкуруючих REST-інтерфейсів одночасно, тема „REST API чи Graph“ була предметом обґрунтованих дискусій. Сьогодні ж йдеться переважно про їх уніфікацію. Процес об’єднання майже завершений, а альтернативи поступово втрачають свою актуальність.