Microsoft Graph lub starsze punkty końcowe REST: przewodnik decyzyjny na rok 2026

Pytanie jest nieco błędne

Każdy, kto łączy aplikację z danymi Microsoft 365, Entra ID, Teams lub Outlook, w końcu szuka odpowiedzi na pytanie „REST API czy Microsoft Graph?”. Brzmi to jak rozsądny wybór pomiędzy dwiema opcjami, ale tak naprawdę nie jest. Sam Microsoft Graph jest w rzeczywistości REST API. Ludzie zazwyczaj mają na myśli coś takiego:

Czy należy nadal korzystać ze starszych, specyficznych dla poszczególnych usług punktów końcowych REST (Azure AD Graph, Outlook REST API, SharePoint REST, EWS i inne), czy przenieść się na zintegrowany Microsoft Graph API?

W 2026 roku do tego pytania przypisane są konkretne terminy. Microsoft spędził około trzech lat na wyłączaniu rozproszonych API i kierowaniu wszystkich ku Graph, a niektóre z tych wyłączeń nastąpią już za kilka tygodni. Poniżej znajdziesz uporządkowaną listę nazw, informacje o stanie funkcjonowania poszczególnych rozwiązań, porównanie obok siebie oraz proces decyzyjny, który możesz zastosować zarówno do nowych wersji, jak i starych integracji.

Uporządkowanie nazw

REST to styl architektoniczny, a nie produkt do zainstalowania. API, które wykorzystuje operatory HTTP takie jak GET, POST, PATCH i DELETE, adresuje elementy jako zasoby za pomocą adresów URL i zazwyczaj wymienia dane w formacie JSON, może słusznie nazywać się RESTful. Zgodnie z tą definicją Microsoft Graph, Azure AD Graph, wycofane Outlook REST API oraz SharePoint REST również spełniają te kryteria.

Microsoft Graph to jedyna REST API, która obejmuje zarówno Microsoft 365, jak i Entra ID. Nie musisz przechodzić między różnymi punktami końcowymi – jednym dla poczty, drugim dla plików, a trzecim dla danych katalogowych. Wszystko znajduje się pod adresem https://graph.microsoft.com/: użytkownicy, grupy, poczta, kalendarze, rozmowy w Teams, pliki, ostrzeżenia bezpieczeństwa, a ostatnio także agenci AI.

Zatem przydatnym porównaniem jest zintegrowany Graph w porównaniu z tradycyjnymi, specyficznymi dla poszczególnych usług interfejsami REST. To, w jakiej sytuacji obecnie znajdują się te starsze API, ma duże znaczenie, ponieważ sytuacja szybko się zmieniała w ciągu ostatniego roku.

Co nadal będzie działać w 2026 roku

Jeśli cokolwiek, co posiadasz, nadal łączy się z graph.windows.net, jesteś już spóźniony – od połowy lipca 2026 roku ta możliwość zostanie zamknięta w ciągu zaledwie kilku tygodni. Stara API Outlook REST nie istnieje już od ponad dwóch lat. Dostęp third-party do EWS w Exchange Online zostanie przerwany tego jesieni. Prawie każdy argument, który kiedyś usprawiedliwiał pozostanie przy natywnym punkcie końcowym REST, albo już wygasł, albo wkrótce to zrobi.

Microsoft już wcześniej zmieniał te terminy, więc przed planowaniem migracji sprawdź aktualny termin na stronie Microsoft Learn. Kierunek rozwoju jednak od lat nie uległ zmianie: wszystko jest integrowane z Graphem.

Graph w porównaniu z tradycyjnymi punktami końcowymi

Trzy różnice mają największe znaczenie w codziennej pracy.

Autoryzacja

Przez ponad dekadę w ramach tego dziedzictwa gromadzono różne opcje autoryzacji: Basic Auth, NTLM, Kerberos oraz Azure Access Control Service, od którego zależały dodatki do SharePoint. W przypadku zadań w Microsoft 365 wszystkie one zostały już wycofane. Graph przyjmuje wyłącznie OAuth 2.0 przez Microsoft Entra ID. Dzięki temu istnieje tylko jeden sposób na uzyskanie tokenów, jeden model uprawnień oraz jedno miejsce do sprawdzania, kto ma dostęp do czego. Dzięki temu administratorzy otrzymują lepszą ochronę, a nie tylko programiści przyjemniejszą API.

Zapytania i grupowanie

Jedno zapytanie do Graph, takie jak poniżej, może filtrować, przetwarzać i przekazywać dane w ramach jednej transakcji:

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

W przypadku starszych, mniej elastycznych punktów końcowych ten sam wynik często wymagał kilku skomplikowanych żądań lub filtrowania po stronie klienta. Dodając $batch, można zapakować do 20 niezależnych operacji w jedno żądanie HTTP, łącząc operacje odczytu i zapisu dotyczące zupełnie różnych typów zasobów.

Throttling

Graph stosuje kilka ograniczeń jednocześnie: na poziomie aplikacji we wszystkich użytkownikach, na poziomie użytkownika we wszystkich aplikacjach oraz na poziomie aplikacji w obrębie jednego użytkownika. Dokładne wartości różnią się w zależności od usługi – poczta, pliki, katalogi oraz komunikatory Teams mają własne limity. Gdy osiągniesz pierwszy z tych limitów, otrzymasz błąd 429 Too Many Requests wraz z nagłówkiem Retry-After, który wskazuje, jak długo należy czekać. W porównaniu z starszymi API, gdzie ograniczenia często nie były udokumentowane i poznawało się je dopiero w warunkach produkcyjnych, jest to duży postęp. Zasada pozostaje ta sama: używaj $select, aby pobierać tylko te pola, których potrzebujesz, preferuj zapytania zbiorcze i delta zamiast pollingu, oraz zawsze przestrzegaj wartości Retry-After, zamiast od razu próbować ponownie.

Gdzie Graph nie jest najlepszym rozwiązaniem

Graph jeszcze nie obejmuje wszystkiego, a niektóre przypadki rzeczywiście wymagają innego API.

• Szczegółowa administracja stroną SharePoint. Pełne informacje na poziomie uprawnień, niektóre operacje grup stron oraz części zarządzania typami treści i schematami list dostępne są jedynie w SharePoint REST pod adresem _api/web/.... Dojrzałe projekty SharePoint zazwyczaj realizują codzienne zadania związane z plikami, listami i dyskami za pomocą Graph, a SharePoint REST używają tylko wtedy, gdy brakuje jakiejś funkcji.
• Części webowe SPFx. Środowisko wykonawcze SharePoint Framework już zapewnia gotowy kontekst SharePoint REST, więc do modyfikacji wewnątrz strony jest to często najprostsze rozwiązanie, chociaż ta sama część webowa może również korzystać z Graph.

Exchange Server lokalny. Blokada z października 2026 roku dotyczy wyłącznie Exchange Online, więc EWS nadal funkcjonuje z Exchange lokalnym. W przypadku pełnej konfiguracji poczty lokalnej rzeczywistym wyborem jest albo EWS, albo najpierw migracja do Exchange Online.

Wielkie, jednorazowe zadania administracyjne. Masowe usuwanie uprawnień, generowanie raportów dla użytkowników oraz skalowane konfigurowanie stron często realizuje się za pomocą narzędzi wyższego poziomu, takich jak PnP PowerShell, które z kolei wewnętrznie korzysta z Graph i SharePoint REST.

Poza tymi ograniczonymi przypadkami nowy projekt ma niewiele technicznych powodów, by rozpocząć pracę przy jednym z starych punktów końcowych dostępnych dla poszczególnych usług w tym roku, ponieważ większość z nich jest już wyłączona lub w trakcie wycofywania.

Jak podjąć decyzję

Przeprowadź każdą nową integrację, odpowiadając na następujące pytania:

1. Czy to nowa wersja oprogramowania? Użyj Microsoft Graph. Nowe funkcje trafiają tam najpierw, a to jedyne rozwiązanie, w które Microsoft nadal inwestuje.
2. Czy istniejące aplikacje korzystają z Azure AD Graph, Outlook REST API lub dodatków SharePoint opartych na ACS? Outlook REST i ACS już przekroczyły swój okres użyteczności, a Azure AD Graph zostanie wycofane 31 lipca 2026 roku. Traktuj to jako pilną sprawę.
3. Czy aplikacje od dostawców zewnętrznych używają EWS do obsługi Exchange Online? Microsoft zacznie blokować takie połączenia 1 października 2026 roku. Zacznij już przenosić się na punkty końcowe do korespondencji i kalendarza w Graph.
4. Czy potrzebujesz funkcji SharePoint, której jeszcze nie ma w Graph? Do tej konkretnej operacji użyj SharePoint REST, a do wszystkiego innego Graph. Najpierw sprawdź dokumentację SharePoint-in-Graph, ponieważ lista brakujących funkcji stale się skraca.

Czy środowisko istnieje wyłącznie lokalnie? W takim przypadku nadal obowiązują EWS oraz inne protokoły lokalne. Microsoft Graph jest skoncentrowany na chmurze i nie może bezpośrednio łączyć się z lokalnymi serwerami Exchange czy SharePoint.

Dla niemal wszystkich sprowadza się to do jednej zasady: używaj Microsoft Graph, chyba że masz konkretny, udokumentowany powód, by tego nie robić.

Ta sama prośba, wtedy i teraz

Oto już nie używany interfejs Outlook REST v2.0, pokazany wyłącznie w celach porównawczych:

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

Od marca 2024 roku ten endpoint odpowiada błędem HTTP 410 Gone. Wersja Graph tego samego żądania wygląda następująco:

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

SharePoint REST, który nadal jest wspierany, odczytuje elementy listy w następujący sposób:

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

Gdzie Graph obsługuje tę samą operację, wywołanie wygląda następująco:

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

Mechanizmy HTTP są identyczne w obu erach. To, co dodaje Graph, to jedna adresacja bazowa, jeden model autoryzacji oraz jedna konwencja JSON, niezależnie od tego, z jaką usługą Microsoft 365 faktycznie komunikujesz się.

Migracja z starszej API

Jeśli dopiero teraz zdałeś sobie sprawę, że coś w twoim tenantie nadal polega na wycofywanej API, przejdź przez tę listę:

1. Dowiedz się, co faktycznie do niej się odwołuje. Entra proponuje dwie rekomendacje: „Migrate Applications” oraz „Migrate Service Principals”, które przedstawiają rzeczywiste wykorzystanie Azure AD Graph zaobserwowane w twoim tenantie w ciągu ostatnich 30 dni. To znacznie lepsze rozwiązanie niż domyślanie się na podstawie kodu źródłowego.
2. Jasno prześlij uprawnienia. Uprawnienia z starszych systemów nie przekładają się w sposób jednoznaczny na zakresy Graph. Korzystaj z oficjalnych referencji Microsoft dotyczących mapowania uprawnień zamiast zakładać, że dwa zakresy o podobnych nazwach są równoważne.
3. Przenieś mechanizm autoryzacji do MSAL. Wszystko, co nadal używa starej biblioteki autoryzacji Azure AD (ADAL), wymaga osobnej, opóźnionej migracji, ponieważ ADAL nie jest już wspierany od lat.
4. Zmień SDK-y, a nie tylko adresy URL. Oficjalne SDK-y Graph dla .NET, JavaScript i TypeScript, Python, Java, Go oraz PowerShell zajmują się automatycznym grupowaniem zapytań, ich ponawianiem oraz stronicowaniem. Nie pisz ręcznie prostych żądań HTTP, chyba że naprawdę musisz to zrobić.
5. Bądź ostrożny z wersją beta. Jeśli dana funkcja istnieje tylko w punkcie końcowym Graph beta, jej specyfikacja może ulec zmianie w każdej chwili. Albo przygotuj się na to, albo poczekaj, aż funkcja stanie się powszechnie dostępna.
6. Znajdź błędy 429 w środowisku testowym. Przeprowadź test obciążeniowy z realistyczną liczbą żądań, abyś sam osiągnął limit przepustowości przed twoimi użytkownikami.
7. Ustaw prawdziwą datę końcową w swoim kalendarzu i sprawdź ją w aktualnej dokumentacji Microsoft tuż przed jej wykorzystaniem. Daty te zmieniały się już wcześniej, więc traktuj każdą datę uzyskaną z innych źródeł, włączając tę stronę, jako tymczasową.

Graph to również miejsce zarządzania agentami AI

Istnieje jeszcze jeden powód, dla którego ta luka się powiększa. Graph staje się płaszczyzną sterowania ekosystemem agentów AI Microsoftu. W 2026 roku Microsoft dodał punkty końcowe Graph do zarządzania agentami i aplikacjami Microsoft 365 Copilot, utrzymywania inventarza agentów oraz pobierania bardziej szczegółowych raportów dotyczących użytkowania Copilot, a także funkcji związanych z nowszymi licencjami, takimi jak Agent 365. Nic z tego nie istnieje w Azure AD Graph, Outlook REST czy EWS i nigdy nie będzie. Jeśli twoja organizacja planuje rozwijać rozszerzalność Copilot lub tworzyć własne agenty, to jest to kolejna ścieżka, która prowadzi wyłącznie do Graph.

Jakie to ma dla ciebie konsekwencje

Na pytanie tytułowe istnieje dość jasna odpowiedź na rok 2026:

• Rozpoczynasz coś nowego w Microsoft 365 lub Entra ID? Użyj Microsoft Graph. Nie ma już przypadków, w których nowy projekt powinien być uruchamiany za pomocą specyficznej dla starych usług API REST.
• Utrzymujesz starszą integrację? Porównaj ją z powyższą tabelą stanów. Jeśli dotyczy ona Azure AD Graph, Outlook REST, dodatków do SharePoint opartych na ACS lub dostępu EWS od dostawców zewnętrznych, masz do spełnienia terminy, a niektóre z nich są już bardzo bliskie.
• Brakuje ci jakiejś funkcji SharePoint w Graph? Wykorzystaj w tym konkretnym przypadku SharePoint REST, a wszystko inne pozostaw w Graph.

W 2018 roku, gdy Microsoft faktycznie uruchamiał kilka konkurencyjnych interfejsów REST obok siebie, dyskusja na temat „REST API czy Graph” była uzasadniona. Dziś chodzi głównie o uporządkowanie sytuacji. Konsolidacja jest już prawie zakończona, a alternatywy tracą czas.