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.
// 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`);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.
| 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 UnipileOd 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.
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.
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.
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.
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.
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.
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.
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ć.
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 EWS
podszywanie 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ę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 |
// 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ślniePunkty 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 APIUwierzytelnianie 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.
Rejestracja aplikacji w Azure AD: 5 kroków
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.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.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.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.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
| 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
// 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'
})
});
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.
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.
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.
<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
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://..."
}
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
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)
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
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
<t:DistinguishedFolderId
Chodzić="skrzynka odbiorcza"/>
NewMailEvent
UsunięteWydarzenie
ŻądanieSubskrypcjiStrumieniowania>
Subskrybuj
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.
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.
| Typ | Kontekst | Zgoda administratora |
|---|---|---|
| Delegowany | Użytkownik zalogowany | Czasami |
| Zastosowanie | Brak użytkownika / demona | Zawsze |
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.
@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.
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.
łą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.
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.
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
// 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']) { /* ... */ }
// 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.
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