Z Outlook REST API i EWS do Microsoft Graph: przewodnik migracyjny dla deweloperów na rok 2026

Unipile - Spis treści
Przewodnik migracji 2026

Od Outlook REST API & EWS do Microsoft Graph

Interfejs API REST programu Outlook w wersji 2.0 został wycofany (marzec 2024). Usługi sieciowe Exchange (EWS) osiągną datę zakończenia eksploatacji 1 października 2026 r. Niniejszy przewodnik obejmuje wszystkie punkty końcowe, przepływy OAuth i kroki migracji, których potrzebujesz, aby zakończyć prace przed terminem.

Ostateczny termin EWS: 1 października 2026 r. Firma Microsoft potwierdziła, że w przypadku usługi Exchange Online nie przewidziano okresu karencji. Rozpocznij migrację już teraz.

graph-mail.js
// Outlook REST API za pośrednictwem Microsoft Graph // Zastąp EWS SOAP pojedynczym wywołaniem REST const response = await fetch( 'https://graph.microsoft.com/v1.0/me/messages', { nagłówki: { 'Authorization': `Bearer ${accessToken}`, 'Content-Type': 'application/json' } } ); const { wartość: wiadomości } = czekać odzew.json(); konsola.log(`Pobrano ${messages.length} wiadomości e-mail`);
GET /me/messages - 200 OK - zwrócono 12 wiadomości
Co to jest

Co to jest interfejs API REST programu Outlook w 2026 roku?

Termin "Outlook REST API" powoduje zamieszanie w 2026 roku, ponieważ Microsoft używał go do opisania co najmniej trzech różnych rzeczy w ciągu ostatniej dekady. Oto dokładne obecne znaczenie, dlaczego nadal jest ważne dla deweloperów i co się zmieniło.

Definicja: W 2026 r. "Outlook REST API" to potoczne określenie punktów końcowych poczty e-mail w usłudze Microsoft Graphhttps://graph.microsoft.com/v1.0/me/messages). Oryginalny, dedykowany interfejs API REST programu Outlook w wersji 2.0 (outlook.office.com/api/v2.0został trwale wycofany 31 marca 2024 r., zwracając błąd HTTP 410 Gone dla wszystkich żądań. Microsoft Graph jest teraz jednolitym, zunifikowanym interfejsem API dla poczty, kalendarza i kontaktów w całym Microsoft 365, Exchange Online, Outlook.com i Teams.

Ma to znaczenie w 2026 roku z dwóch powodów: po pierwsze, każda aplikacja nadal odwołująca się do starego outlook.office.com/api/ domena jest uszkodzona. Po drugie, aplikacje korzystające z Exchange Web Services (EWS) – starszego protokołu opartego na SOAP – napotkają termin ostatecznego wdrożenia w dniu 1 października 2026 r. dla Exchange Online. Zrozumienie prawidłowej nomenklatury jest pierwszym krokiem do udanej migracji.

Wyjaśnienie nazwy
Nazwa Protokół URL bazowy Status w 2026
Outlook REST API w wersji 2.0 REST / JSON outlook.office.com/api/v2.0 Zmarły (marzec 2024)
Exchange Web Services (EWS) SOAP / XML outlook.office365.com/EWS/ Koniec eksploatacji październik 2026
Microsoft Graph API poczty REST / JSON graph.microsoft.com/v1.0/ja/wiadomości Na żywo - Użyj tego
MAPI / Outlook COM COM / Binarny Tylko na pulpit Tylko na pulpit

Aby zgłębić integrację z Microsoft Graph poza pocztą e-mail (webhooks, zapytania delta, skrzynki współdzielone), zobacz Przewodnik po integracji poczty e-mail z Microsoft Graph API. Przewodnik po filarach obejmujący wszystkie wzorce API do obsługi poczty e-mail znajduje się pod adresem Przewodnik deweloperski API poczty e-mail.

Budujesz na Outlook w 2026 roku? Unipile oferuje zunifikowane API poczty e-mail, które obsługuje Microsoft Graph, Gmail i IMAP za pomocą jednej integracji – bez potrzeby migracji per dostawca.

Zbuduj to z Unipile
Oś czasu

Od v2.0 do Microsoft Graph: Krótka historia

Deprecjacja interfejsu API REST programu Outlook v2.0 nie nastąpiła nagle – Microsoft ogłosił ją z wieloletnim wyprzedzeniem, wielokrotnie przesuwając terminy. Zrozumienie tej historii pomaga przewidzieć, co Microsoft zrobi z EWS i dlaczego termin październik 2026 jest traktowany jako ostateczny.

2015 - 2017
Outlook REST API v2.0 wystartowało

Microsoft wprowadza API oparte na REST pod adresem outlook.office.com/api/v2.0 Jako nowoczesna alternatywa dla EWS. Deweloperzy mogą odczytywać pocztę, zarządzać wydarzeniami w kalendarzu i uzyskiwać dostęp do kontaktów za pomocą JSON przez HTTPS - co stanowi znaczną poprawę w stosunku do SOAP/XML.

2019
Microsoft Graph wyłania się jako ujednolicony interfejs API

Microsoft uruchamia Microsoft Graph jako pojedynczy punkt końcowy obejmujący wszystkie usługi Microsoft 365 – pocztę, kalendarz, kontakty, Teams, OneDrive, SharePoint i inne. graph.microsoft.com domena staje się kanonicznym sposobem programowego dostępu do danych firmy Microsoft.

Listopad 2020
Ogłoszenie o wycofaniu interfejsu API REST programu Outlook w wersji 2.0

Microsoft oficjalnie ogłasza wycofanie Outlook REST API v2.0 (i wersji beta v1.0), wskazując Microsoft Graph jako zamiennik. Komunikat wyraźnie stwierdza, że stare punkty końcowe przestaną działać – z terminem "późny 2022" w tamtym czasie.

2022 - 2023
Wielokrotne przedłużenia terminów

Microsoft dwukrotnie przedłużył termin – najpierw do listopada 2022 r., potem do marca 2023 r., a następnie do marca 2024 r. Każdemu przedłużeniu towarzyszyło ostrzeżenie: "to jest ostatnie przedłużenie". Wielu deweloperów potraktowało te przedłużenia jako sygnał, że terminy są elastyczne. Termin EWS na październik 2026 r. jest egzekwowany bardziej rygorystycznie.

31 marca 2024
Interfejs API REST programu Outlook w wersji 2.0 został trwale wycofany

The outlook.office.com/api/v2.0 endpoint zwraca HTTP 410 Gone dla wszystkich żądań. Koniec z rozszerzeniami. Każda aplikacja nadal wywołująca te adresy URL jest uszkodzona. "Outlook REST API" oznacza teraz Microsoft Graph, gdy jest używany poprawnie. Pełny przewodnik po integracji z punktami końcowymi poczty Microsoft Graph można znaleźć pod adresem Przewodnik po integracji poczty e-mail z Microsoft Graph API.

1 października 2026
EWS koniec życia dla Exchange Online

Exchange Web Services przestaną działać dla Exchange Online (chmura Microsoft 365). Microsoft potwierdził, że jest to ostateczny termin wdrożenia. Dotyczy to aplikacji chmurowych korzystających z wywołań EWS opartych na SOAP/XML, które muszą zostać przeniesione do Microsoft Graph przed tą datą. Serwery Exchange zainstalowane lokalnie nie są dotknięte tą zmianą.

Dlaczego ta migracja była nieunikniona

Nowoczesne bezpieczeństwo OAuth 2.0

Starsze interfejsy API opierały się na uwierzytelnianiu podstawowym i starszych formatach tokenów. Microsoft Graph wymusza OAuth 2.0 z Azure Active Directory, zgodnie z modelami bezpieczeństwa zero-trust i eliminując ryzyko ujawnienia danych uwierzytelniających.

Zunifikowana Platforma Identyfikacji

Microsoft Graph konsoliduje dostęp do każdej usługi Microsoft 365 za pośrednictwem jednej platformy tożsamości. Jedna rejestracja aplikacji, jeden token, jeden prefiks punktu końcowego – w przeciwieństwie do utrzymywania oddzielnych danych uwierzytelniających dla starszych interfejsów API.

Bogatsze możliwości

Microsoft Graph udostępnia funkcje, których EWS nigdy nie miało: zapytania przyrostowe do synchronizacji przyrostowej, powiadomienia o zmianach (webhooks), wyszukiwanie we wszystkich treściach, integracja z Teams i analitykę specyficzną dla Graph - wszystko za pośrednictwem czystego REST/JSON.

Unipile - Koniec życia EWS
Termin krytyczny

Prawdziwy termin: koniec życia EWS (1 października 2026 r.)

Chociaż wycofanie interfejsu API REST programu Outlook w wersji 2.0 dotknęło stosunkowo niewielką grupę deweloperów, zakończenie obsługi EWS w usłudze Exchange Online jest znacznie większym wydarzeniem. Tysiące aplikacji korporacyjnych, klientów poczty, narzędzi do synchronizacji kalendarza i rozwiązań do tworzenia kopii zapasowych nadal opiera się na Exchange Web Services. 1 października 2026 r. nastąpi ostateczne przejście – oto, co musisz wiedzieć.

EWS Ostateczny Termin: 1 października 2026 - Brak Okresu Krakowskiego

Zakres Tylko Exchange Online (chmura Microsoft 365). Serwery Exchange w infrastrukturze lokalnej nie są objęte zmianami. Egzekwowanie Microsoft potwierdził, że jest to twarde przełączenie - żądania EWS do Exchange Online przestaną być przetwarzane. Co się łamie: wszystkie wywołania SOAP/XML do outlook.office365.com/EWS/Exchange.asmx, w tym aplikacje korzystające z biblioteki EWS Managed API .NET, przepływy uwierzytelniania Kerberos/NTLM oraz Basic Auth przez EWS.

Kogo to dotyczy

  • Niestandardowe klienty poczty e-mail oparte na EWS Managed API
  • Dodatki do programu Outlook wykorzystujące wywołania EWS (nie oparte na Graph)
  • Aplikacje do synchronizacji kalendarza (rezerwacja sal, harmonogramy)
  • Narzędzia do tworzenia kopii zapasowych i archiwizacji poczty e-mail
  • Integracje synchronizacji poczty e-mail CRM / ATS
  • Każda aplikacja korzystająca z UsługaWymiany .Klasa .NET

Co przestaje działać

  • Uwierzytelnianie NTLM i Kerberos
  • Podstawowe uwierzytelnianie przez EWS (już przestarzałe)
  • EWS Managed API (Microsoft.Exchange.WebServices)
  • Strumieniowanie powiadomień przez EWS
  • Podszywanie się pod EWSpodszywanie się pod Exchange)
  • Operacje SOAP: GetItem, FindItems, SyncFolderItems

Czego Nie Dotyczy

  • Exchange 2016 / 2019 / SE on-premises EWS
  • Microsoft Graph API (to jest cel migracji)
  • IMAP / SMTP do podstawowego wysyłania/odbierania
  • ActiveSync (przestarzałe osobno)
  • Aplikacja desktopowa Outlook (używa własnościowego MAPI)

Oś czasu migracji - Rzeczywistość

  • Prosta aplikacja z 1-2 operacjami EWS: 1-2 tygodnie
  • Średnio-skomplikowana aplikacja (poczta + kalendarz + kontakty): 4-8 tygodni
  • Aplikacja firmowa z podszywaniem się pod EWS: 8-16 tygodni
  • Zależność od dostawcy (oczekiwanie na aktualizację biblioteki): niekontrolowana
  • Testy + UAT + wdrożenie na produkcję: dodaj 2-4 tygodnie

Na ograniczony czas migracji EWS? Zunifikowane API poczty e-mail Unipile abstrahuje Microsoft Graph (a także Gmail i IMAP), dzięki czemu możesz migrować raz i nigdy więcej nie dotykać kodu specyficznego dla dostawcy. Zobacz pełny przewodnik po API poczty elektronicznej dla wzorców architektonicznych.

Rozpocznij swoją migrację
API Reference

Punkty końcowe interfejsu API REST programu Outlook w 2026 roku (przez Microsoft Graph)

Cała funkcjonalność Outlook REST API jest teraz udostępniana za pośrednictwem Microsoft Graph pod adresem https://graph.microsoft.com/v1.0. Poniżej znajdują się kluczowe punkty końcowe poczty, kalendarza i kontaktów wraz z ich metodami HTTP i przykładowym kodem dla każdej kategorii.

Punkty końcowe poczty

Metoda Punkt końcowy Opis Wymagany zakres
GET /ja/wiadomości Wyświetl listę wiadomości w skrzynce odbiorczej (obsługuje filtry $filter, $orderby, $top oraz opcję $select) Mail.Read
GET /ja/wiadomości/{id} Pobierz pojedynczą wiadomość według identyfikatora z pełną treścią i nagłówkami Mail.Read
POST /ja/wyslijEmail Wyślij nową wiadomość e-mail natychmiast (bez zapisywania wersji roboczej) Mail.Send
POST /ja/wiadomości Utwórz szkic wiadomości (wyślij osobno przez /send) Mail.ReadWrite
PATCH /ja/wiadomości/{id} Zaktualizuj wiadomość (oznacz jako przeczytaną, przenieś, zmień kategorie) Mail.ReadWrite
USUŃ /ja/wiadomości/{id} Usuń wiadomość na stałe Mail.ReadWrite
GET /ja/folderyPoczty Wyświetl wszystkie foldery poczty (Skrzynka odbiorcza, Wysłane, Wersje robocze, niestandardowe) Mail.Read
GET /ja/wiadomości/delta Przyrostowa synchronizacja - pobieranie tylko zmienionych wiadomości od ostatniej synchronizacji Mail.Read
send-mail.js
// POST /me/sendMail - Wyślij przez Outlook REST API (Microsoft Graph) const response = czekać fetch('https://graph.microsoft.com/v1.0/ja/tylko/wyslijEmail', { metoda: 'POST', nagłówki: { 'Authorization': `Bearer ${accessToken}`, 'Content-Type': 'application/json' }, ciało: JSON.stringify({ message: { podmiot: 'Witaj z Microsoft Graph', ciało: { typTreści: 'Tekst', zawartość: 'Migracja EWS zakończona!' }, doOdbiorców: [{ adresEmail: { Adres: 'user@example.com' } }] }, Zapisz w elementach wysłanych: true }) }); // 202 Zaakceptowano = wysłano pomyślnie

Punkty końcowe kalendarza

Metoda Punkt końcowy Opis Wymagany zakres
GET /ja/wydarzenia Wyświetl wszystkie wydarzenia w kalendarzu (obsługuje filtr $ według daty rozpoczęcia/zakończenia) Kalendarze.Odczyt
GET /ja/widokKalendarza Pobierz wydarzenia w zakresie czasowym (parametry startDateTime + endDateTime) Kalendarze.Odczyt
POST /ja/wydarzenia Utwórz nowe wydarzenie w kalendarzu z uczestnikami i powtarzaniem Kalendarze.OdczytZapis
GET /ja/kalendarze Wymień wszystkie kalendarze użytkownika (podstawowy, udostępniony, grupowy) Kalendarze.Odczyt

Punkty końcowe kontaktów

Metoda Punkt końcowy Opis Wymagany zakres
GET /ja/kontakty Wyświetl wszystkie kontakty w domyślnym folderze kontaktów Kontakty.Odczyt
POST /ja/kontakty Utwórz nowy kontakt Kontakty.CzytajPisanie
GET /ja/folderyKontaktów Lista folderów kontaktów Kontakty.Odczyt

Chcesz jedno API obsługujące REST Outlooka (Microsoft Graph), Gmail i IMAP? Unipile obejmuje wszystkie trzy za pomocą jednego zunifikowanego punktu końcowego. Porównaj dostawców pod adresem porównanie dostawców API e-mail.

Tworzenie aplikacji przy użyciu zunifikowanego interfejsu API
Uwierzytelnianie

Uwierzytelnianie OAuth 2.0: Jedyna droga naprzód

NTLM, Kerberos i uwierzytelnianie podstawowe zostały wycofane z Microsoft 365. OAuth 2.0 jest teraz obowiązkową metodą uwierzytelniania dla każdego żądania Microsoft Graph API. Nie ma możliwości powrotu do poprzedniego stanu, trybu zgodności ani przedłużenia terminu. Jeśli Twoja aplikacja nadal korzysta ze starszych przepływów uwierzytelniania, jest już zablokowana dla nowych dzierżaw i całkowicie przestanie działać dla wszystkich dzierżaw po zakończeniu egzekwowania EWS w październiku 2026 r.

Status uwierzytelniania starszego oprogramowania (maj 2026): Protokoły NTLM i Kerberos są całkowicie wyłączone w usłudze Exchange Online. W październiku 2022 r. wycofano uwierzytelnianie podstawowe w usłudze Exchange Online. Jedyną akceptowaną metodą uwierzytelniania w usłudze Microsoft Graph jest OAuth 2.0 za pośrednictwem usługi Azure AD.

Rejestracja aplikacji w Azure AD: 5 kroków

01
Zarejestruj aplikację w Azure AD
Idź do portal.azure.com - Azure Active Directory - Rejestracje aplikacji - Nowa rejestracja. Wybierz nazwę, ustaw obsługiwany typ konta (pojedynczy dzierżawca, wielu dzierżawców lub konta osobiste) i skonfiguruj adres URI przekierowania.
02
Skonfiguruj uprawnienia API
Pod Uprawnienia API, dodaj uprawnienia Microsoft Graph. Wybierz uprawnienia Delegowane (kontekst użytkownika) lub Aplikacji (demona) w zależności od przypadku użycia. Większość integracji poczty e-mail/kalendarza korzysta z uprawnień Delegowanych.
03
Utwórz sekret klienta (lub certyfikat)
Pod Certyfikaty i sekrety, utwórz nowy sekret klienta. Natychmiast skopiuj wartość – wyświetlana jest tylko raz. W przypadku aplikacji produkcyjnych certyfikat jest bezpieczniejszy niż sekret klienta.
04
Zaimplementuj przepływ kodu autoryzacji
Przekieruj użytkowników do https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize z client_id, zakres, przekierowanie_urioraz typ_odpowiedzi=kod. Po uzyskaniu zgody, wymień kod na tokeny w punkcie końcowym tokenów.
05
Poproś o zgodę administratora, jeśli jest potrzebna
Niektóre zakresy (np. Mail.ReadWrite.All) wymagać zgody administratora dzierżawy, zanim którykolwiek użytkownik będzie mógł autoryzować. W tym celu użyj punktu końcowego zgody administratora: /adminconsent przepływ z kontem administratora dzierżawy.

Wymagane zakresy OAuth dla interfejsu Graph API

Przesuń w poziomie, aby zobaczyć pełną tabelę
Zakres Typ Przypadek użycia
Mail.Read Delegowany Przeczytaj wiadomości z poczty użytkownika
Mail.ReadWrite Delegowany Czytaj i modyfikuj wiadomości w skrzynce pocztowej
Mail.Send Delegowany Wyślij wiadomość e-mail w imieniu użytkownika
Kalendarze.OdczytZapis Delegowany Wyświetlanie i edycja wydarzeń w kalendarzu
Kontakty.Odczyt Delegowany Czytaj kontakty użytkownika
Mail.ReadWrite.All Zastosowanie Odczyt/zapis wszystkich skrzynek pocztowych (aplikacje demona, wymaga zgody administratora)
Kalendarze.Odczyt i zapis.Wszystkie Zastosowanie Odczytuj/zapisuj wszystkie kalendarze (aplikacje z usługą w tle, wymaga zgody administratora)
dostęp offline Delegowany Wymagane, aby otrzymać token odświeżający w celu długoterminowego dostępu

Przepływ kodu autoryzacji - przykład w Node.js

JavaScript (Node.js)
// Krok 1: Zbuduj adres URL autoryzacji
const authUrl = `https://login.microsoftonline.com/${tenantId}/oauth2/v2.0/authorize?`
  + nowy URLSearchParamsid_klienta: CLIENT_ID,
    typ_odpowiedzi: 'kod',
    redirect_uri: REDIRECT_URI,
    zakres: 'Mail.Read Mail.Send Calendars.ReadWrite offline_access',
    tryb_odpowiedzi: 'zapytanie'
  });

// Krok 2: Wymiana kodu na tokeny
const tokenRes = czekać fetch(
  `https://login.microsoftonline.com/${tenantId}/oauth2/v2.0/token`,
  {
    metoda: 'POST',
    ciało: nowy URLSearchParams({
      client_id: CLIENT_ID,
      client_secret: KLUCZ_SEKRETNY,
      kod: authCode,
      redirect_uri: REDIRECT_URI,
      grant_type: 'kod_autoryzacji'
    })
  }
);
const { access_token, refresh_token } = czekać tokenRes.json();

// Krok 3: Odśwież po wygaśnięciu tokena dostępu (zazwyczaj po godzinie)
const Odśwież = czekać fetch(punktKońcowyTokenu, {
  metoda: 'POST',
  body: nowy URLSearchParamsid_klienta: CLIENT_ID,
    client_secret: KLUCZ_SEKRETNY,
    token_odświeżania: odświeżającyToken,
    grant_type: 'token odświeżający'
  })
});
Obsługa tokenu odświeżania: Tokeny dostępu Microsoft Graph wygasają po 1 godzinie. Przechowuj token_odświeżający bezpiecznie w Twojej bazie danych i wykorzystywać je do żądania nowych tokenów dostępu bez konieczności ponownego uwierzytelniania użytkownika. Tokeny odświeżania mogą wygasnąć po 90 dniach bezczynności. Zawsze żądaj dostęp offline zakres do otrzymania tokenu odświeżającego.
Plan Działania

Lista kontrolna migracji: EWS do Microsoft Graph w 10 krokach

Microsoft potwierdził bezwzględne egzekwowanie wycofania EWS dla Exchange Online od 1 października 2026 r. Nie będzie okresu przejściowego, opcji powrotu ani mostu kompatybilności. Każda aplikacja nadal korzystająca z Exchange Web Services dla Microsoft 365 przestanie działać w tym terminie.

Ostateczny termin: 1 października 2026 r. Żadnych rozszerzeń. Brak trybu zgodności. Zaplanuj migrację już teraz – złożona aplikacja EWS może wymagać od 4 do 8 tygodni na pełną migrację do Microsoft Graph.
01
Przeanalizuj bieżące użycie EWS
Sporządź spis wszystkich wywołań EWS w swojej bazie kodu: operacje pocztowe, synchronizacja kalendarza, zapytania dotyczące kontaktów, powiadomienia push/pull/streaming. Określi to zakres i szacowane nakłady pracy związane z migracją.
02
Zarejestruj aplikację Azure AD i zdefiniuj zakresy
Zarejestruj swoją aplikację w Azure portal. Zdefiniuj minimalne wymagane zakresy Microsoft Graph dla Twojego przypadku użycia. Żądaj tylko tego, czego potrzebujesz – unikaj nadmiernych uprawnień.
03
Mapowania operacji EWS do punktów końcowych programu Graph
Stwórz tabelę tłumaczeń: FindItem staje się GET /me/messages, CreateItem staje się POST /me/sendMail, FindAppointments staje się GET /me/events. Microsoft udostępnia oficjalny przewodnik po mapowaniu EWS-na-Graph.
04
Zamień WCF/SOAP na wywołania REST HTTP
EWS używa SOAP przez HTTP. Microsoft Graph używa standardowego REST z JSON. Usuń wszystkie klasy proxy WCF, serializację SOAP XML i zależności EWS Managed API ze swojej bazy kodu.
05
Migracja uwierzytelniania z przestarzałych protokołów do OAuth 2.0
Zastąp NTLM, Kerberos lub Basic Auth przepływem kodu autoryzacyjnego OAuth 2.0. Zaimplementuj logikę odświeżania tokenu przy użyciu zakresu offline_access, aby utrzymać długoterminowy dostęp.
06
Test w dzierżawie deweloperskiej przy użyciu narzędzia Microsoft Graph Explorer
Użyj Graph Explorera (developer.microsoft.com/graph/graph-explorer) do prototypowania i testowania wywołań API przed napisaniem kodu. Skonfiguruj oddzielny dzierżawcę deweloperski, aby uniknąć testowania na skrzynkach pocztowych produkcyjnych.
07
Zaimplementuj zapytania delta do synchronizacji przyrostowej
Zastąp EWS SyncFolderItems zapytaniami delta Graph (GET /me/messages/delta). Przechowuj token deltaLink, aby umożliwić efektywną synchronizację przyrostową - zwracane są tylko zmiany od czasu ostatniego zapytania.
08
Obsługa ograniczania przepustowości: HTTP 429 i Retry-After
Microsoft Graph wymusza ścisłe limity żądań. Zaimplementuj wykładnicze wycofywanie: po otrzymaniu odpowiedzi HTTP 429 odczytaj nagłówek Retry-After i wstrzymaj się dokładnie na ten okres przed ponowną próbą.
09
Zaktualizuj obsługę błędów dla formatu błędów programu Graph
Błędy grafów używają innego formatu niż błędy SOAP EWS. Przeanalizuj obiekt błędu JSON: { "error": { "code": "...", "message": "..." } }. Zaktualizuj odpowiednio obsługę błędów i logowanie.
Termin
10
Przełączenie produkcyjne przed 1 października 2026 r.
Zaplanuj swoje przejście produkcyjne co najmniej 4 tygodnie przed terminem. Uruchom jednocześnie EWS i Graph podczas okresu przejściowego, aby zweryfikować poprawność, zanim całkowicie wycofasz warstwę EWS.
Migruj do Unipile i pomiń 8 z 10 kroków - brak rejestracji aplikacji Azure, brak przepływów OAuth, brak logiki ograniczania ruchu do zarządzania.
Buduj teraz
Przykłady kodu

Przykłady migracji kodu: EWS vs Microsoft Graph

Poniżej porównano cztery typowe operacje obok siebie: starsze podejście EWS SOAP po lewej stronie i odpowiednik Microsoft Graph REST po prawej. Zmiana z rozwlekłego formatu XML na przejrzysty format JSON jest od razu widoczna.

1 Odczytaj wiadomości w skrzynce odbiorczej
EWS - ZnajdźElement SOAP Przestarzałe
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types">
  
    ZnajdźPrzedmiot Przechodzenie="Płytki"
      przestrzeń nazw XML="http://schemas.microsoft.com/exchange/services/2006/messages">
      
        Domyślne
      
      <WidokPozycjiIndeksowanej
        MaksymalnaLiczbaZwróconychWpisów="10"
        Przesunięcie="0"
        Punkt Bazowy="Początek"/>
      
        <t:DistinguishedFolderId Chodzić="skrzynka odbiorcza"/>
      
    ZnajdźPrzedmiot
  
Microsoft Graph REST Obecny
GET /ja/wiadomości
  ?$select=temat,od,receivedDateTime,bodyPreview
  &$top=10
  &$orderby=receivedDateTime malejąco

Autoryzacja: Bearer {access_token}

// Odpowiedź (JSON):
{
  "wartość": [
    {
      "id": "AAMkAGI...",
      "temat": "Cześć",
      "od": {
        "adresEmail": {
          "adres": "sender@example.com"
        }
      },
      "dataOtrzymania": "2026-05-27T..."
    }
  ],
  "@odata.nextLink": "https://..."
}
2 Wyślij wiadomość e-mail
EWS - CreateItem SOAP Przestarzałe
UtwórzElement Rozporządzenie w sprawie wiadomości="Wyślij i zapisz kopię"
  przestrzeń nazw XML="http://schemas.microsoft.com/.../wiadomości">
  
    
      Witaj z EWSTemat
      <t:Ciało Typ nadwozia="HTML">
        

Treść wiadomości

to@example.com
Microsoft Graph REST Obecny
POST /ja/wyslijEmail
Autoryzacja: Bearer {access_token}
Content-Type: application/json

{
  "wiadomość": {
    "temat": "Witaj z Grafu",
    "ciało": {
      "typTreści": "HTML",
      "zawartość": "

Treść wiadomości

"
}, "odbiorcy": [ { "adresEmail": { "adres": "to@example.com" } } ] }, "zapiszWElementachWysłanych": true } // Odpowiedź: HTTP 202 Zaakceptowano (brak ciała)
3 Pobierz wydarzenia z kalendarza
EWS - ZnajdźSpotkania SOAP Przestarzałe
ZnajdźPrzedmiot Przechodzenie="Płytki">
  
    WszystkieWłaściwości
  
  WidokKalendarza
    MaksymalnaLiczbaZwróconychWpisów="50"
    DataRozpoczęcia="2026-05-01T00:00:00Z"
    Data końcowa="2026-05-31T23:59:59Z"
  />
  
    <t:DistinguishedFolderId
      Chodzić="kalendarz"/>
  
ZnajdźPrzedmiot
Microsoft Graph REST Obecny
POBIERZ /ja/wydarzenia
  ?$select=temat,początek,koniec,lokalizacja,organizator
  &$filter=start/dateTime ge '2026-05-01T00:00:00Z'
    oraz koniec/czas-data le '2026-05-31T23:59:59Z'
  &$top=50
  &$orderby=start/dateTime rosnąco

Autoryzacja: Bearer {access_token}

// Zwraca czystą tablicę JSON z
// obiekty zdarzeń kalendarza - bez parsowania XML
4 Subskrybuj zmiany w czasie rzeczywistym
EWS – Powiadomienia strumieniowe Przestarzałe

  
    
      <t:DistinguishedFolderId
        Chodzić="skrzynka odbiorcza"/>
    
    
      NewMailEvent
      UsunięteWydarzenie
    
  
Subskrybuj



Mikrosoft Graph Webhooki Obecny
POST /subskrypcje
Autoryzacja: Bearer {access_token}
Content-Type: application/json

{
  "zmianaTypu": "utworzono,zaktualizowano,usunięto",
  "urlPowiadomienia": "https://yourapp.com/webhook",
  "zasób": "/ja/wiadomosci",
  "dataWaznosci": "2026-06-03T18:00:00Z",
  "stanKlienta": "twój-tajny-stan"
}

// Graf wysyła POST do twojego adresu URL przy każdej zmianie.
Odnów subskrypcję przed wygaśnięciem.
// Brak wymaganego stałego połączenia.
Uważaj

Częste pułapki: uprawnienia, limity żądań, dławienie

Nawet programiści mający doświadczenie z Exchange Web Services regularnie napotykają te same przeszkody podczas migracji do Microsoft Graph. Te 6 pułapek odpowiada za większość incydentów produkcyjnych podczas migracji. Zrozumienie ich teraz pozwoli zaoszczędzić dni debugowania później. Aby uzyskać szerszą perspektywę na temat tego, jak te wyzwania porównują się między dostawcami, zobacz naszą Porównanie dostawców API do obsługi poczty e-mail.

Uprawnienia aplikacji vs. uprawnienia delegowane
To najczęstsze nieporozumienie. Delegowany Uprawnienia działają w imieniu zalogowanego użytkownika. Zastosowanie Uprawnienia działają jako usługa bez kontekstu użytkownika i wymagają zgody administratora.
TypKontekstZgoda administratora
DelegowanyUżytkownik zalogowanyCzasami
ZastosowanieBrak użytkownika / demonaZawsze
Limity dławienia: HTTP 429 i Retry-After
Microsoft Graph narzuca limit około 10 000 żądań na 10 minut na aplikację na najemcę. Po zadławieniu otrzymujesz HTTP 429 with a Ponów-Po nagłówek określający czas oczekiwania w sekundach. Zignorowanie tego nagłówka i ponowienie próby natychmiast spowoduje przedłużenie blokady. Zawsze stosuj wykładnicze wycofywanie z dokładną wartością Retry-After.
Paginacja przez @odata.nextLink
Graf paginuje wyniki z domyślnym rozmiarem strony (zazwyczaj 10 wiadomości). Jeśli nie sprawdzisz @odata.nextLink w odpowiedzi cicho pomijasz dane. Zawsze pętla: jeśli @odata.nextLink jeśli jest obecny, wykonaj kolejne żądanie GET do tego adresu URL (zawiera token pominięcia), dopóki pole nie będzie nieobecne.
Zgoda administratora dla wrażliwych zakresów
Zakresy takie jak Mail.ReadWrite.All, Kalendarze.Odczyt i zapis.Wszystkieoraz Użytkownik.Odczyt.Wszystkie wymagać od administratora najemcy udzielenia zgody, zanim którykolwiek użytkownik będzie mógł autoryzować Twoją aplikację. Bez zgody administratora przepływ OAuth zwraca AADSTS65001 błąd. Użyj /adminconsent punkt końcowy podczas wdrażania aplikacji dla klientów korporacyjnych.
Stan zapytania delty: zarządzanie deltaLink
Zapytania delty zwracają zmiany od ostatniej synchronizacji, zidentyfikowane przez łącze delta token na ostatniej stronie. Przechowuj ten token trwale - jest on twoim kursorem synchronizacji. Jeśli go zgubisz, musisz przeprowadzić pełną synchronizację. Nigdy nie koduj na stałe zakresu czasu - użyj deltaLink, aby uniknąć przetwarzania duplikatów lub brakujących zmian.
Obsługa załączników: limit rozmiaru 3 MB
Załączniki poniżej 3 MB można dołączyć bezpośrednio w jednym wywołaniu API. W przypadku plików większych niż 3 MB, najpierw należy utworzyć sesję przesyłania (POST /ja/wiadomości/{id}/załączniki/utwórzSesjęPrzesyłaniai przesyłanie w fragmentach. Próba umieszczenia dużego załącznika wewnątrz tekstu skutkuje 413 Encja żądania jest za duża błąd.
Zunifikowane podejście API

Omiń Kłopoty z Migracją: Zunifikowane Podejście API do Poczty E-mail

Pełna migracja EWS do Graph w przypadku złożonej aplikacji zajmuje od 4 do 8 tygodni pracy inżynierów. Należy zarejestrować aplikacje platformy Azure, zaimplementować przepływy OAuth, obsłużyć odświeżanie tokenów, zarządzać limitami, przepisać każde wywołanie SOAP, zaktualizować obsługę błędów i przetestować w różnych środowiskach. Następnie powtórzyć to samo, gdy Microsoft coś zmieni.

Unipile agreguje Microsoft Graph, Gmail i IMAP pod jednym, ujednoliconym API. Uwierzytelniasz użytkowników raz poprzez Unipile i odczytujesz/wysyłasz e-maile, synchronizujesz kalendarze oraz zarządzasz kontaktami we wszystkich trzech dostawcach za pomocą tych samych punktów końcowych – bez rejestracji aplikacji Azure, bez przepływów OAuth dla poszczególnych dostawców, bez konieczności utrzymywania logiki ograniczania przepustowości. Zobacz nasze Kompletny przewodnik po API poczty e-mail oraz Porównanie dostawców interfejsów API do obsługi poczty e-mail aby zrozumieć krajobraz.

50 linii Microsoft Graph w porównaniu do 5 linii Unipile

Microsoft Graph - Odczytaj skrzynkę odbiorczą (natywna) ~50 linii
// 1. Rejestracja aplikacji Azure (portal.azure.com)
// 2. Przepływ kodu autoryzacji OAuth
const authUrl = `https://login.microsoftonline.com/${tenantId}/oauth2/v2.0/authorize?`
  + nowy URLSearchParams({
      client_id: CLIENT_ID,
      response_type: 'kod',
      redirect_uri: REDIRECT_URI,
      scope: 'Mail.Read offline_access',
      tryb_odpowiedzi: 'zapytanie'
    });
// 3. Obsługa przekierowania, wymiana kodu na tokeny
const tokenRes = czekać fetch(`https://login.microsoftonline.com/${tenantId}/oauth2/v2.0/token`, {
  metoda: 'POST',
  body: nowy URLSearchParams({
    client_id: CLIENT_ID, client_secret: CLIENT_SECRET,
    code: authCode, redirect_uri: REDIRECT_URI,
    grant_type: 'kod_autoryzacji'
  })
});
const { access_token, refresh_token } = czekać tokenRes.json();
// 4. Przechowuj tokeny dostępu i odświeżania po wygaśnięciu (co godzinę)
// 5. Wywołanie Grafu z tokenem Bearer
const res = czekać fetch('https://graph.microsoft.com/v1.0/me/messages?$top=10', {
  nagłówki: { Autoryzacja: `Bearer ${access_token}` }
});
// 6. Obsłuż ograniczanie (HTTP 429 + Retry-After)
jeśli (res.status === 429) {
  const PróbujPonowniePo = res.nagłówki.uzyskać('Ponawiam po');
  czekać senpróbujPonowniePo 1000);
  // ponów...
}
// 7. Paginacja za pomocą @odata.nextLink
const dane = czekać rez.json();
niech komunikaty = dane.wartość;
podczas (dane['@odata.nextLink']) { /* ... */ }
Unipile - Czytaj skrzynkę odbiorczą (unified API) 5 linii
// Brak aplikacji w Azure, nie ma potrzeby wdrażania procesów OAuth,
// brak logiki ograniczania przepustowości, brak odświeżania tokenów.
// Działa dla Outlooka, Gmaila I IMAP.

const klient = nowy UnipileClient(Klucz API);

const wiadomości = czekać client.email.listMessages({
  account_id: IdentyfikatorUżytkownika, // połączone konto
  folder: 'SKRZYNKA',
  limit: 10
});

// Ten sam kod, ten sam format odpowiedzi
// dla Outlook, Gmail i IMAP.
// Unipile obsługuje OAuth, ograniczanie szybkości,
// stronicowanie i odświeżanie tokenów.
SOC 2 Typ II
Zgodność z RODO
CASA Poziom 2
Umowa SLA dotycząca dostępności na poziomie 99,991%
Outlook + Gmail + IMAP
Przestań przepłacać za tę samą armaturę OAuth
Czytaj e-maile, wysyłaj wiadomości, synchronizuj kalendarze między Outlookiem, Gmailem i IMAP za pomocą jednego API. Unipile zajmuje się złożonością migracji z EWS do Graph, dzięki czemu Twój zespół może wdrażać funkcje zamiast przepływów uwierzytelniania.
Zacznij budować z Unipile
Unipile - FAQ dotyczące Outlook REST API i EWS

Outlook REST API i EWS – Często zadawane pytania

Najczęściej zadawane pytania dotyczące wycofania Outlook REST API, deprecjacji EWS i migracji do Microsoft Graph

Nie. Interfejs API REST programu Outlook (wersja 2.0 i beta) został wycofany przez firmę Microsoft. Wszystkie żądania do starszych punktów końcowych REST programu Outlook kończą się teraz niepowodzeniem. Oficjalnym zamiennikiem jest Microsoft Graph, który obejmuje wszystkie te same operacje poczty e-mail i kalendarza, a nawet znacznie więcej. Jeśli Twoja aplikacja nadal korzysta z punktów końcowych programu Outlook REST, migracja do programu Graph nie jest opcjonalna.

API REST programu Outlook była dedykowaną usługą REST obejmującą wyłącznie operacje na skrzynce pocztowej programu Outlook. Microsoft Graph jest ujednoliconym interfejsem API dla całego ekosystemu Microsoft 365: poczty programu Outlook, kalendarza, kontaktów, Teams, SharePoint, OneDrive i innych. Oba wykorzystują uwierzytelnianie OAuth 2.0, ale Graph używa pojedynczego adresu URL podstawowego. https://graph.microsoft.com/v1.0 i oferuje bardziej spójny, bogaty w funkcje interfejs niż wycofane punkty końcowe specyficzne dla programu Outlook.

Microsoft ustawił 1 października 2026 jako data ścisłego egzekwowania wycofania EWS w usłudze Exchange Online (Microsoft 365). Po tej dacie EWS nie będzie działać w przypadku skrzynek pocztowych Microsoft 365. Nie ma okresu karencji ani ogłoszonego przedłużenia. EWS nadal będzie działać w przypadku instalacji serwera Exchange w infrastrukturze lokalnej, które nie są objęte tym terminem.

Microsoft Graph jest oficjalnym zamiennikiem EWS. Każda operacja EWS ma odpowiednik w usłudze Graph: ZnajdźPrzedmiot staje się GET /ja/wiadomości, UtwórzPrzedmiot (wysłać e-mail) staje się POST /ja/wyslijEmail, powiadomienia strumieniowe stają się webhookami sieci grafów poprzez POST /subskrypcje. Zmiana uwierzytelniania z NTLM/Kerberos/Basic Auth na OAuth 2.0 przez Azure AD. Dla zespołów, które potrzebują prostszego rozwiązania, dostępny jest ujednolicone API do obsługi poczty elektronicznej, podobne do Unipile abstraktyzuje wszystkich trzech dostawców pod jednym zestawem SDK.

Nie. Wersja 2.0 Outlook REST API została wycofana. Żądania do tych punktów końcowych zakończą się błędami. Microsoft Graph jest jedynym obsługiwanym sposobem integracji poczty e-mail i kalendarza Outlooka. Wszystkie nowe integracje muszą być kierowane https://graph.microsoft.com/v1.0 i użyj uwierzytelniania OAuth 2.0.

Nakład pracy zależy od złożoności Twojej implementacji EWS. Prosta integracja z kilkoma operacjami odczytu/zapisu zazwyczaj zajmuje 1-2 tygodnie. Złożona aplikacja ze strumieniowymi powiadomieniami, synchronizacją przyrostkową, operacjami na wielu folderach i rozbudowaną obsługą błędów może zająć 4-8 tygodni. Migracja wymaga: rejestracji aplikacji w Azure AD, implementacji protokołu OAuth 2.0, zamiany punktu końcowego na punkt końcowy, logiki ograniczania przepustowości, aktualizacji stronicowania i zmian formatu błędów. Alternatywą jest użycie Abstrakcja Microsoft Graph firmy Unipile, który obsługuje większość tej złożoności automatycznie.

Termin w październiku 2026 dotyczy konkretnie Exchange Web Services (EWS) Użycie w Exchange Online. Dodatki programu Outlook korzystające z interfejsu API Office.js mają inny harmonogram. Jednak firma Microsoft wycofuje starsze dodatki COM i VSTO na rzecz internetowych dodatków Office. Jeśli dodatek wewnętrznie wykonuje wywołania EWS, wywołania te przestaną działać w październiku 2026 r., niezależnie od platformy dodatku. Sprawdź roadmapę Microsoft 365, aby uzyskać najnowsze wskazówki dotyczące Twojego typu dodatku.

Ponieważ interfejs API REST programu Outlook został wycofany, odpowiednie zakresy są dla Microsoft Graph. Kluczowe zakresy e-mail: Mail.Read (czytaj wiadomości), Mail.Send (wyślij e-mail), Mail.ReadWrite (czytaj i modyfikuj wiadomości), Kalendarze.OdczytZapis (dostęp do kalendarza), Kontakty.Odczyt (kontakty). Zawsze dołączaj dostęp offline żeby odebrać token odświeżania. Zakresy na poziomie aplikacji, takie jak Mail.ReadWrite.All wymaga zgody administratora dzierżawy i powinien być używany wyłącznie w scenariuszach demonów bez kontekstu użytkownika. Zobacz nasze Przewodnik OAuth po Microsoft Graph aby przeprowadzić pełny samouczek konfiguracji.

Microsoft Graph egzekwuje limity żądań w przybliżeniu 10 000 żądań na 10 minut dla każdej aplikacji w każdej dzierżawie. Po osiągnięciu limitu, interfejs API zwraca HTTP 429 Zbyt wiele żądań with a Ponów-Po nagłówek określający dokładną liczbę sekund do oczekiwania. Krytyczna zasada: zawsze przestrzegaj Ponów-Po dokładnie. Ponowne próby przed zamknięciem tego okna wydłużają okres ograniczania. W przypadku aplikacji SaaS wielodostępnych, w których każdy najemca ma oddzielne limity, ograniczanie jednego najemcy nie wpływa na innych. Porównaj również IMAP jako alternatywa jeśli skalowanie przepustowości jest problemem.

Unipile to ujednolicone API pocztowe które agreguje Microsoft Graph, Gmail i IMAP pod jedną biblioteką SDK. Zamiast implementować przepływy uwierzytelniania OAuth Microsoft Graph, zarządzać tokenami dostępu, obsługiwać ograniczenia przepustowości i pisać kod specyficzny dla każdego dostawcy, łączysz konta swoich użytkowników za pośrednictwem Unipile i korzystasz z jednego, spójnego interfejsu API dla wszystkich trzech dostawców. Jest to szczególnie skuteczne w przypadku aplikacji SaaS, które muszą jednocześnie obsługiwać Outlook i Gmail bez utrzymywania oddzielnego kodu integracyjnego dla każdego z nich. Unipile działa jako niezależny pośrednik techniczny, działając w imieniu każdego uwierzytelnionego użytkownika, i nie jest powiązany ani wspierany przez firmę Microsoft.

Pomiń całkowicie migrację EWS. Nasz zespół jest do Twojej dyspozycji.

Buduj teraz
pl_PLPL