Microsoft Graph oder herkömmliche REST-Endpunkte: Ein Entscheidungshilfe-Handbuch für 2026

Die Frage ist etwas falsch gestellt

Jeder, der eine Anwendung mit Microsoft 365, Entra ID, Teams oder Outlook-Daten verbindet, sucht letztendlich nach einer Entscheidung zwischen „REST API oder Microsoft Graph?“. Es klingt nach einer fairen Wahl zwischen zwei Optionen, ist aber nicht ganz richtig. Microsoft Graph ist selbst eine REST API. Was die Leute normalerweise meinen, ist Folgendes:

Soll man weiterhin die älteren, servicebezogenen REST-Endpunkte verwenden (Azure AD Graph, die Outlook REST API, SharePoint REST, EWS und ähnliches), oder sollte man auf die einheitliche Microsoft Graph API wechseln?

Im Jahr 2026 sind für diese Frage konkrete Fristen festgelegt. Microsoft hat etwa drei Jahre damit verbracht, die fragmentierten APIs abzuschalten und alle Nutzer auf Graph umzulenken, wobei einige dieser Abschaltungen bereits in wenigen Wochen stattfinden. Unten finden Sie eine geordnete Auflistung der Namen, einen Statusbericht darüber, was noch funktioniert, einen Vergleich Seite an Seite sowie einen Entscheidungsprozess, den Sie sowohl auf neue Versionen als auch auf alte Integrationen anwenden können.

Ordnung in den Namen bringen

REST ist ein Architekturstil – es handelt sich dabei nicht um ein Produkt, das man installiert. Eine API, die HTTP-Verben wie GET, POST, PATCH und DELETE verwendet, Ressourcen über URLs adressiert und in der Regel JSON austauscht, kann zu Recht als RESTful bezeichnet werden. Nach dieser Definition erfüllen Microsoft Graph, Azure AD Graph, die eingestellte Outlook REST API sowie SharePoint REST alle Kriterien.

Microsoft Graph ist die einzige REST-API, die Microsoft 365 und Entra ID zusammen abdeckt. Man muss nicht zwischen einem Endpunkt für E-Mails, einem anderen für Dateien und einem dritten für Verzeichnisdaten wechseln. Alles befindet sich unter https://graph.microsoft.com/: Benutzer, Gruppen, E-Mails, Kalender, Teams-Chats, Dateien, Sicherheitswarnungen – und in letzter Zeit auch KI-Agenten.

Die sinnvolle Vergleichsbasis ist daher der vereinigte Graph im Vergleich zu den veralteten, service-spezifischen REST-Schnittstellen. In welchem Zustand sich diese veralteten APIs derzeit befinden, ist sehr wichtig, denn die Situation hat sich im vergangenen Jahr schnell verändert.

Was im Jahr 2026 noch funktioniert

Falls irgendetwas, das Sie besitzen, weiterhin auf graph.windows.net zugreift, sind Sie bereits im Rückstand; ab Mitte Juli 2026 schließt sich diese Möglichkeit innerhalb von ein paar Wochen. Die alte Outlook REST API ist bereits seit über zwei Jahren nicht mehr verfügbar. Der Zugriff Dritter auf Exchange Online über EWS wird diesen Herbst eingestellt. Fast jeder Grund, der einst die Verwendung eines nativen REST-Endpunkts rechtfertigte, ist entweder bereits hinfällig oder steht kurz davor.

Microsoft hat bereits mehrfach diese Fristen verschoben, daher sollten Sie die aktuelle Frist auf Microsoft Learn überprüfen, bevor Sie eine Migration entsprechend planen. Die Richtung hat sich jedoch seit Jahren nicht geändert: Alles wird auf Graph konzentriert.

Graph im Vergleich zu den herkömmlichen Endpunkten

Drei Unterschiede sind im täglichen Einsatz am wichtigsten.

Authentifizierung

Im Laufe von mehr als einem Jahrzehnt sammelten sich zahlreiche Authentifizierungsverfahren an: Basic Auth, NTLM, Kerberos sowie der Azure Access Control Service, auf den SharePoint-Add-Ins angewiesen waren. Für Microsoft 365-Arbeitslasten wurden all diese Verfahren bereits eingestellt. Graph akzeptiert ausschließlich OAuth 2.0 über Microsoft Entra ID. Dadurch gibt es nur eine Methode zur Erhaltung von Tokens, ein einziges Berechtigungsmodell sowie einen einzigen Ort, um zu überprüfen, wer auf welche Ressourcen zugreifen kann. Dadurch profitieren nicht nur Entwickler von einer besseren API, sondern auch Administratoren von verbesserten Sicherheitsmaßnahmen.

Abfragen und Batching

Eine Graph-Anfrage wie die unten stehende kann E-Mails in einer einzigen Anfrage filtern, bearbeiten und paginieren:

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

Gegenüber den älteren, weniger flexiblen Endpunkten erforderte derselbe Ergebnis oft mehrere spezifische Anfragen oder Filterung auf der Client-Seite. Mit $batch können bis zu 20 unabhängige Operationen in einer einzigen HTTP-Anfrage zusammengefasst werden, wobei Lese- und Schreibvorgänge unterschiedlichster Ressourcentypen miteinander kombiniert werden können.

Drosselung

Graph wendet mehrere Beschränkungen gleichzeitig an: pro Anwendung für alle Mieter, pro Mieter für alle Anwendungen sowie pro Anwendung innerhalb eines Mieters. Die genauen Zahlen unterscheiden sich je nach Service – E-Mail, Dateien, Verzeichnisse sowie die Teams-Nachrichtenfunktion legen jeweils ihre eigenen Obergrenzen fest. Sobald eine dieser Grenzen erreicht wird, wird 429 Too Many Requests zurückgegeben, zusammen mit einem Retry-After-Header, der anzeigt, wie lange man warten soll. Im Vergleich zu den alten APIs, bei denen das Throttling oft nicht dokumentiert war und man die Grenzen erst in der Produktion erfuhr, ist das ein großer Fortschritt. Der Rat ist alt, aber immer noch richtig: Verwenden Sie $select, um nur die benötigten Felder abzurufen, bevorzugen Sie Batch- und Delta-Anfragen gegenüber Polling und respektieren Sie stets den Retry-After-Header, anstatt sofort erneut zu versuchen.

Wo etwas anderes als Graph noch sinnvoll ist

Graph deckt noch nicht alles ab, und einige Fälle erfordern tatsächlich eine andere API.

• Detaillierte Verwaltung von SharePoint-Seiten. Vollständige Details zu Berechtigungsstufen, bestimmte Operationen an Seitengruppen sowie Teile der Verwaltung von Inhaltstypen und Listen sind nur über SharePoint REST unter _api/web/... verfügbar. Ausgereifte SharePoint-Projekte erledigen im Alltag die Arbeit mit Dateien, Listen und Laufwerken über Graph und nutzen SharePoint REST nur für das, was fehlt.
• SPFx-Webparts. Der SharePoint Framework-Runtime stellt bereits einen fertigen SharePoint REST-Context bereit, wodurch kundenspezifische Anpassungen auf der Seite oft der einfachste Weg sind – obwohl derselbe Webpart auch Graph aufrufen kann.

On-premises Exchange Server. Die Blockade für Oktober 2026 gilt nur für Exchange Online, sodass EWS weiterhin mit on-premises Exchange funktioniert. Für eine vollständig lokale E-Mail-Infrastruktur steht entweder EWS zur Verfügung oder es muss zunächst auf Exchange Online migriert werden.

Größere einmalige Admin-Aufgaben. Massenhafte Berechtigungsanpassungen, Berichterstattung für Mieter sowie großangelegte Einrichtungen von Sites werden oft mit höherstufigen Tools wie PnP PowerShell durchgeführt, welches intern sowohl Graph als auch SharePoint REST nutzt.

Ausgenommen diese spezifischen Fälle gibt es dieses Jahr kaum technische Gründe, ein völlig neues Projekt an einem der alten Service-Endpunkte zu starten, da die meisten bereits nicht mehr verfügbar sind oder ausgemustert werden.

Wie man sich entscheidet

Prüfen Sie jede neue Integration anhand folgender Fragen:

1. Handelt es sich um eine neue Version? Verwenden Sie Microsoft Graph. Neue Funktionen werden dort zuerst bereitgestellt, und es ist die einzige Plattform, in die Microsoft weiterhin investiert.
2. Ruft eine bestehende Anwendung Azure AD Graph, die Outlook REST API oder SharePoint-Add-ins auf Basis von ACS auf? Outlook REST und ACS haben bereits ihr Lebensende erreicht, und Azure AD Graph wird am 31. Juli 2026 eingestellt. Behandeln Sie dies als dringende Aufgabe.
3. Verwendet eine Anwendung Dritter EWS gegen Exchange Online? Microsoft beginnt ab dem 1. Oktober 2026, solche Aufrufe zu blockieren. Wechseln Sie bereits jetzt auf die E-Mail- und Kalender-Endpunkte von Graph.
4. Brauchen Sie eine SharePoint-Funktion, die Graph noch nicht bietet? Verwenden Sie für diesen einen Aufruf SharePoint REST und für alles andere Graph. Prüfen Sie zunächst die Dokumentation zu SharePoint in Graph, da die Liste der fehlenden Funktionen stetig kürzer wird.

Ist die Umgebung nur lokal vorhanden? EWS sowie andere lokale Protokolle sind dort weiterhin gültig. Microsoft Graph ist cloud-basiert und kann nicht direkt auf lokale Exchange- oder SharePoint-Server zugreifen.

Für fast alle lässt sich das auf eine Regel reduzieren: Verwenden Sie Microsoft Graph, es sei denn, Sie haben einen spezifischen, dokumentierten Grund dagegen.

Derselbe Anfrageaufbau, damals und heute

Hier ist der eingestellte Outlook REST v2.0-Anfrageaufbau, der nur zu Vergleichszwecken gezeigt wird:

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

Seit März 2024 antwortet dieser Endpunkt mit HTTP 410 Gone. Die Graph-Version derselben Anfrage sieht so aus:

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

SharePoint REST, das weiterhin unterstützt wird, liest Listeinträge wie folgt:

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

Wo Graph dieselbe Operation unterstützt, sieht der Aufruf so aus:

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

Die Mechanismen von HTTP sind in beiden Epochen identisch. Was Graph hinzufügt, ist eine Basis-URL, ein Authentifizierungsmodell sowie eine JSON-Konvention – unabhängig davon, mit welchem Microsoft 365-Dienst man eigentlich arbeitet.

Umstieg von einer veralteten API

Falls Ihnen gerade aufgefallen ist, dass etwas in Ihrem Tenant noch auf einer eingestellten API angewiesen ist, gehen Sie diese Liste durch:

1. Erfahren Sie, was die API tatsächlich aufruft. Entra bietet zwei Empfehlungen an, „Anwendungen migrieren“ und „Dienstprinzipale migrieren“, die die tatsächliche Nutzung von Azure AD Graph in Ihrem Tenant in den letzten 30 Tagen auflisten. Das ist bei weitem besser als das Raten anhand des Quellcodes.
2. Karten Sie die Berechtigungen explizit ab. Veraltete Berechtigungen lassen sich nicht eins zu eins in Graph-Scope umwandeln. Verwenden Sie stattdessen Microsofts offizielle Referenzen zur Zuordnung von Berechtigungen, anstatt anzunehmen, dass zwei Scope mit ähnlichen Namen gleichwertig sind.
3. Verlagern Sie die Authentifizierung auf MSAL. Alles, was noch auf der alten Azure AD Authentication Library (ADAL) basiert, muss separat migriert werden, da ADAL bereits seit Jahren nicht mehr unterstützt wird.
4. Wechseln Sie die SDKs, nicht nur die URLs. Die offiziellen Graph SDKs für .NET, JavaScript und TypeScript, Python, Java, Go und PowerShell kümmern sich automatisch um Batching, Wiederholungsversuche und Paginierung. Schreiben Sie nur dann rohe HTTP-Anfragen manuell, wenn es unbedingt notwendig ist.
5. Seien Sie vorsichtig mit der Beta-Version. Wenn eine Funktion nur am beta-Graph-Endpunkt verfügbar ist, kann sich deren Schnittstelle jederzeit ändern. Planen Sie entweder damit oder warten Sie, bis sie allgemein verfügbar ist.
6. Erkennen Sie 429-Fehler im Staging-Umfeld. Führen Sie Lasttests mit realistischen Anfragenmengen durch, damit Sie bereits vor Ihren Nutzern an die Begrenzungen stoßen.
7. Tragen Sie das tatsächliche Enddatum in Ihren Kalender ein und überprüfen Sie es vor der Nutzung gegen die aktuelle Dokumentation von Microsoft. Diese Daten haben sich bereits zuvor geändert, daher sollten Sie jedes Datum, das Sie aus zweiter Hand erhalten – einschließlich dieser Seite – als vorläufig betrachten.

Graph ist auch der Ort, an dem KI-Agenten verwaltet werden

Es gibt noch einen weiteren Grund, warum die Lücke weiter wächst. Graph entwickelt sich zum Steuerungsplan für Microsofts KI-Agenten-Ökosystem. Im Jahr 2026 fügte Microsoft Graph-Endpunkte hinzu, um Microsoft 365 Copilot-Agenten und -Anwendungen zu verwalten, ein Inventar der Agenten zu führen sowie detailliertere Copilot-Nutzungsberichte sowie Funktionen, die mit neueren Lizenzen wie Agent 365 verbunden sind, abzurufen. All das existiert weder in Azure AD Graph, Outlook REST noch EWS und wird es auch niemals tun. Wenn Ihre Organisation plant, auf der Erweiterbarkeit von Copilot oder auf benutzerdefinierten Agenten aufzubauen, führt das ebenfalls nur zu Graph.

Was bleibt Ihnen übrig

Die Frage zum Titel hat im Jahr 2026 eine ziemlich klare Antwort:

• Starten Sie etwas Neues mit Microsoft 365 oder Entra ID? Verwenden Sie Microsoft Graph. Es gibt keinen Fall mehr, in dem ein neues Projekt mit einer REST-API eines veralteten Services gestartet werden sollte.
• Warten Sie eine ältere Integration auf? Vergleichen Sie sie mit der obigen Statustabelle. Wenn sie Azure AD Graph, Outlook REST, SharePoint-Add-ins basierend auf ACS oder Zugriff über EWS von Drittanbietern verwendet, arbeiten Sie gegen einen Zeitrahmen an – und einige dieser Fristen sind bereits sehr nah.
• Fehlt in Graph eine bestimmte SharePoint-Funktion? Verwenden Sie für diesen einen Aufruf SharePoint REST und belassen Sie alles andere bei Graph.

Noch im Jahr 2018, als Microsoft tatsächlich mehrere konkurrierende REST-Schnittstellen nebeneinander betrieb, war „REST API oder Graph“ ein berechtigtes Diskussionsthema. Heute geht es hauptsächlich um Aufräumarbeiten. Die Konsolidierung ist fast abgeschlossen, und den Alternativen läuft die Zeit aus.