Mailbox Import/Export Graph API’leri GA: EWS’in Sonu Geldi
Bakın şimdi, bu haber beni biraz eski günlere götürdü. Yıllardır kurumsal müşterilerde Exchange Web Services (EWS) ile uğraşan biri olarak — evet, liste baya uzun — Microsoft’un mailbox import/export Graph API’lerini genel kullanıma (GA) açtığını görünce ister istemez durup baktım. Resmî duyuru da gelmiş, tamamdır.
Ama açık konuşayım: Bu iş sadece “yeni bir API geldi” meselesi değil. EWS’in emekliliği yaklaşırken, yıllardır kenarda bekleyen kurumsal göç senaryoları için artık bir harekete geçme işareti var, hatta biraz gecikmiş bir işaret; çünkü bazı ekipler bu işi epey erteledi, sonra bir baktık ki takvim çoktan ilerlemiş. Peki neden şimdi? İşte tam burada asıl mesele başlıyor.
Peki neden?
Neden Bu Konu Bu Kadar Önemli?
Bak şimdi, EWS, 2007’den beri hayatımızdaydı. Yanı neredeyse her büyük Exchange entegrasyonunun altında o vardı, backup ürünleri vardı, e-discovery çözümleri vardı, üçüncü parti arşivleme yazılımları vardı; hepsi bir şekilde EWS’e yaslanmıştı (ilk duyduğumda inanamadım). Microsoft “bunu emekli ediyoruz” dediğinde, açık konuşayım, bir anda yüzlerce ürünün mimarı notları masadan düşmüş gibi öldü.
Geçen yıl public preview ile bu API’leri tanıttıklarında, bir bankacılık müşterimizde tam da şu soruyu dönüp dolaşıp konuşuyorduk: “EWS gidince arşivleme stratejimiz ne olacak?” Cevap o günlerde biraz flu idi. Şimdi GA ile birlikte, en azından primary ve shared mailbox senaryoları için elde tutulur bir yol var. Ama durun, iş burada bitmiyor; her şey çözülmüş değil, birazdan oraya da geleceğim.
Bunu biraz açayım.
EWS, OAuth tarafında hep biraz topallıyordu ve modern güvenlik beklentilerini de pek karşılayamıyordu. Graph üzerinden gelen bu yeni API’ler işe, 2025 sonrası dünyada elimizi biraz olsun rahatlatacak gibi dürüyor.
GA ile Gelen Yetenekler — Tek Tek
Ne yalan söyleyeyim, Microsoft’un duyuruda saydığı özellikleri kuru kuru tekrarlamak yerine, ben biraz işin sahadaki tarafını anlatayım. Çünkü dokümanda tek cümle diye geçen şey, bazen ekiple iki gün oturup test etmek, sonra bir köşede loglara bakıp “hmm, burası niye böyle” demek oluyor.
Mailbox Hierarchy Discovery
Garip gelecek ama, Mailbox’ın klasör hiyerarşisini gezebiliyorsunuz. Inbox, Sent Items, custom klasörler, alt klasörler… Hepsine programatik olarak erişip içerideki item’ları sayabiliyorsunuz. Eskiden EWS’te FindFolder ve FindItem ile yaptığımız şeyin Graph tarafındaki karşılığı gibi düşünebilirsiniz; yanı çok şaşırtıcı bir şey değil ama iş görüyor.
Full-Fidelity Item Desteği
Bu kısım kritik, çünkü işin canı burada çıkıyor. Mesajlar, contact’lar, takvim girdileri — hepsi IPM subtree içinde dürüyor; “full-fidelity” lafı da boşuna söylenmiyor, item’ı kaybedilen bir attachment ya da bozulan bir property olmadan alıp geri yükleyebiliyorsunuz. Geçen yıl bir telekom projesinde EWS ile migration yaparken bazı custom property’lerin kaybolduğunu fark etmiştik — günler kaybetmiştik o iş için; Graph’ın yeni modeli en azından bu derdi azaltmayı hedefliyor.
Extended Properties
Single-value ve multi-value extended property desteği var. Bu da üçüncü parti uygulamaların Outlook item’larına kendi metadata’sını yazabilmesi demek. CRM entegrasyonları, compliance tool’ları, retention sistemleri… Hepsi bu alanlara yaslanıyor zaten. E peki, sonuç ne öldü? Yoksa GA seviyesine gelmesi biraz zor olurdu, açık konuşayım.
Evet.
Granular Permission Scopes
Bence en sevdiğim taraf burası. Bir uygulamaya “sadece import yap, export yapma” diyebiliyorsunuz; hatta “yalnızca şu mailbox’ları oku” diye de daraltabiliyorsunuz. Eski EWS’te FullAccess verip sonra da “umarım kötüye kullanmaz” modunda kalıyorduk. Şey… modern güvenlik yaklaşımı açısından bu baya eski kafalı kalıyordu.
Daha açık söyleyeyim, peki neden?
Kapsam: Neyi Kapsıyor, Neyi Kapsamıyor?
Şimdi işin biraz daha kaygan tarafına geldik. GA diye bakınca insanın aklına “tamamdır, bitti” geliyor ama öyle değil; kapsam hâlâ yarım yamalak dürüyor. Aşağıdaki tabloyu çıkarırken açık konuşayım, özellikle archive mailbox tarafında içim pek rahat etmedi.
| Mailbox Tipi | GA Durumu | Pratik Etki |
|---|---|---|
| Primary Mailbox | ✅ Destekleniyor | Standart kullanıcı senaryolarının %80’i |
| Shared Mailbox | ✅ Destekleniyor | Departman ve fonksiyonel hesaplar |
| Archive Mailbox | ❌ Henüz yok | Compliance ve uzun vadeli arşivleme bekliyor |
| Public Folders | ❌ Henüz yok | Eski mimaride takılı kalanlar için sorun |
| Group Mailboxes | ❌ Henüz yok | Microsoft 365 Group senaryoları beklemede |
Evet, temel kutular destekleniyor. Ama mesele tam da burada bitmiyor (inanın bana). Microsoft bu eksiklerin üstünde çalışıyor diyor, ben de buna tamamen sırtımı dönmüyorum; yine de danışman gözüyle bakınca “ileride gelir” cümlesi proje takvimine pek oturmuyor, hele archive mailbox tarafı büyükse (kurumsal tarafta 100GB+ archive görmek hiç şaşırtıcı değil) planı şimdilik kenarda tutmak gerekiyor (ciddiyim)
Peki, peki neden? Çünkü compliance işi şaka kaldırmıyor.
Neyse, lafı fazla uzatmayayım; şu an tablo net: primary. Shared tarafında yol var, diğerleri için işe biraz daha beklemek gerekiyor.
Türkiye’deki Kurumlar İçin Bu Ne Anlama Geliyor?
Bu kısmı bilerek ekliyorum, çünkü Türkiye’de Exchange Online göçleri biraz kendi kafasına göre ilerliyor. Bizim müşterilerin epey bir kısmı — özellikle finans ve telekom tarafı — yıllardır hibrit Exchange yapısı kullanıyor. Yanı bir yanda Exchange Server on-prem dürüyor, öbür yanda Exchange Online akıyor; EWS de bu iki dünya arasında sessizce çalışan tutkal gibiydi. GitHub Copilot’un Nisan Güncellemeleri: VS Code’da Sessiz Devrim yazımızda bu konuya da değinmiştik.
Logosoft’ta bir kamu kurumunda yürüttüğümüz projede bunu net gördüm. Tahmin eder mısınız? Müşteri 5 yıllık archive verisini cloud’a taşımak istiyordu, ama EWS göçü için ortada ciddi bir tarih baskısı yoktu; şimdi bu yeni API’ler GA olunca planı yeniden kurmaları gerekiyor, fakat archive mailbox desteği gelmeden iş tam bitmiyor — yanı garip ama gerçek, GA duyurusu bazı ekiplerde rahatlatmak yerine kafa karıştırdı bile. Bu konuyla ilgili GitHub Copilot Modernize 101: Kodun Yorgunluğunu Kırmanın Yeni Yolu yazımıza da göz atmanızı tavsiye ederim.
Küçük ve orta ölçekli işletmeler için tablo daha sade. Eğer 500 kullanıcının altındaysanız ve archive kullanmıyorsanız, bu API’leri test etmeye hemen başlayabilirsiniz; maliyet tarafında da Graph API çağrıları için ayrı bir lisans gerekmiyor, Microsoft 365 lisansınız varsa kullanabiliyorsunuz. TL bazında ekstra bir kalem çıkmıyor yanı. Daha fazla bilgi için .NET 10 ile WebAssembly Hızlanınca Copilot Studio’da Neler Değişti? yazımıza bakabilirsiniz.
Kısa bir not düşeyim buraya.
Pratik Bir Örnek: Folder Listeleme
Somut bir şeyle ilerleyelim. Bir kullanıcının mailbox folder hiyerarşisini almak istiyorsanız, Graph API tarafında iş aslında oldukça düz gidiyor; ama küçük bir detay var, önü atlayınca sonra kafa karışıyor:
GET https://graph.microsoft.com/v1.0/users/{user-id}/mailFolders
Authorization: Bearer {access_token}
# Response (kısaltılmış)
{
"value": [
{
"id": "AAMkAD...",
"displayName": "Inbox",
"totalItemCount": 1247,
"childFolderCount": 3
},
{
"id": "AAMkAD...",
"displayName": "Archive",
"totalItemCount": 8934,
"childFolderCount": 12
}
]
}Tuhaf ama, Burada gördüğünüz şey, klasörlerin kaba bir haritası gibi düşünebilirsiniz. Peki sonra ne oluyor? Sonrasında tek tek item export etmek için ayrı endpoint çağırıyorsunuz, dönen stream’i saklıyorsunuz ve gerektiğinde import ediyorsunuz; Microsoft’un özellikle altını çizdiği nokta şu: bu stream formatı opak, yanı açıp içine bakayım, biraz kurcalayayım derseniz yolun sonu pek hoş olmuyor.
Çok konuştum, örnekle göstereyim.
Araya gireyim: Evet.
Araya gireyim: Sadece export edin, saklayın, import edin. Bu kadar basit görünüyor ama işte hayatı nokta da burada; bu pattern dışına çıkarsanız destek tarafı size pek sıcak bakmıyor, hatta çoğu zaman doğrudan “bu senaryo bizim önerdiğimiz akış değil” deyip kenara çekiliyorlar. Daha fazla bilgi için geldi ile ilgili önceki yazımız yazımıza bakabilirsiniz.
İlk Adımlar İçin Önerim
- Önce dev tenant’ınızda bir test app registration yapın, gerekli permission’ları verin; küçük başlayın ki sorun çıktığında nerede patladığını rahat görün. — ciddi fark yaratıyor
- Küçük bir mailbox üzerinde folder listing testleri yapın — hiyerarşiyi anlayın, çünkü ilk bakışta basit duran yapı bazen beklenmedik şekilde dallanıp budaklanıyor. (bu kritik)
- Tek bir item’ı export edip aynı mailbox’a farklı bir folder’a import etmeyi deneyin; mesela burada akış doğru mu diye kontrol edin, sonra ufak ufak genişletin.
- Throttling davranışını ölçün — kaç paralel istek geçiyor, ne zaman 429 dönüyor; açık konuşayım, bunu baştan bilmezseniz production’da suratınıza çarpıyor.
- Ancak bundan sonra production planına geçin. Acele etmeyin.
Bu sırayı atlamayın. Gördüğüm hataların yarısı, ekiplerin doğrudan production verisiyle test yapmasından kaynaklanıyordu; yanı önce laboratuvar gibi düşünün, sonra gerçek ortama geçin, yoksa küçük görünen şeyler büyüyüp can sıkıyor. Daha fazla bilgi için Kubernetes v1.36 Pod-Level In-Place Resize: Beta’ya Yükseldi yazımıza bakabilirsiniz.
Bakın, ne yalan söyleyeyim, Tam da öyle.
Enterprise vs Startup Yaklaşımı
Burada biraz ayrım yapmak gerekiyor. Çünkü iki tarafın derdi aynı değil, hatta bazen aynı masada konuşuyor gibi dursalar da bambaşka şeyler istiyorlar.
Startup ya da SMB iseniz: büyük ihtimalle bir ISV backup/archiving ürünü kullanıyorsunuzdur. Endişe etmeyin; Veeam, AvePoint, Barracuda gibi ürünler zaten kendi tarafında uyum işini toparlayacak gibi dürüyor. Sizin asıl yapmanız gereken şey basit: vendor’a gidip “EWS deprecation roadmap’ınız ne?” diye sormak (ciddiyim). Cevap netse tamamdır, rahat nefes alırsınız; ama cevap yuvarlaksa, işte o zaman alternatif bakmaya başlamak lazım. Peki neden? Çünkü bu tip belirsizlikler sonra insanın önüne sessizce çıkar, tam en yoğun dönemde.
Açıkçası, Enterprise yapıdaysanız: durum biraz daha karışık. Muhtemelen içeride yıllardır çalışan, ekibin kendi yazdığı custom EWS tabanlı entegrasyonlar var (compliance, e-discovery, custom reporting… liste uzayıp gidiyor). Şimdi açık konuşayım, bu kodları kim yazdı, hâlâ şirkette mi, dokümantasyon gerçekten dürüyor mu? Bu soruların cevabını bulun. Sonra Graph migration planını altı aydan kısa düşünmeyin; ben olsam bir yıl koyardım,. Test döngüsü uzuyor, regression çıkıyor, bir de üstüne hiç beklemediğiniz kenar senaryoları geliyor (bizzat test ettim). Evet.
Yaşadığım Bir Hata: Permission Karmaşası
Preview döneminde bir POC yaparken başıma gelen küçük ama sınır bozucu bir şeyi anlatayım. Mailbox import tarafında Mail.ReadWrite yetmiyor; işin içine import scope’u giriyor, yanı ilk bakışta “bu zaten yeterli” diyorsun ama sonra 403 tokadı geliyor.
Bunu biraz açayım.
Şunu fark ettim: İlk denemede ben de öyle oldum. Bir saat boyunca app registration içinde oradan oraya baktım, ayarları kurcaladım, consent tarafını kontrol ettim, hatta sorun bende mi diye iki kere geri döndüm; meğer yeni granular scope’lar portal UI’da pek net görünmüyormuş, manifest üzerinden eklemek gerekiyormuş.
Şunu söyleyeyim, Evet.
Daha açık söyleyeyim, şimdi GA ile bu taraf toparlanmış olmalı, en azından öyle umuyorum; yine de sız işi şansa bırakmayın, scope dokümanına bir göz atın, çünkü bazen en basit görünen izin detayı bütün akışı kilitleyebiliyor. İlginç, değil mi? Boşuna saç baş yolmayın.
Bağlantılı Konular ve Diğer Yazılarım
Modern Microsoft 365 tarafında kimlik, ajan yönetimi, bir de şu meşhur API göçü var ya, bunlar yeniden konuşuluyor. Eğer bu tarafa biraz daha eğilmek istiyorsanız, daha önce yazdığım Entra Agent ID GA: Sponsor Grup Tipi Kuralları Değişti yazısı baya iş görür. Hatta bazen insan şunu düşünüyor: “Tamam, konu kimlik diye başladık ama iş agent tarafına kaydı.” Neyse, oraya da girince taşlar biraz yerine oturuyor. Graph API’leri üstünden yapay zekâ ajanı kurmayı düşünüyorsanız, Microsoft Agent Framework ile.NET’te Ajan Kurmanın İncelikleri de güzel bir tamamlayıcı olur; özellikle pratik tarafta neyin nereye bağlandığını görmek açısından.
Cloud kontrol senaryolarında veri egemenliği deyince iş biraz sertleşiyor, çünkü konu sadece teknik değil, hukukî. Operasyonel tarafı da var. Bak şimdi, bu yüzden Microsoft Sovereign Private Cloud: Azure Local ile Ölçek Büyürken Kontrolü Kaybetmemek yazımı da öneririm — özellikle kamu ve regüle sektörlerde mailbox verisinin nerede durduğu sorusu bir anda masanın ortasına geliyor. Kısa cevap yok. Uzun cevap işe biraz daha karışık, çünkü veri bazen bölgeye göre, bazen politika setine göre, bazen de bildiğiniz eski alışkanlıklara göre şekilleniyor; işte tam burada Azure Local tarafı devreye giriyor. Kontrol hissini fena olmayan bir seviyede tutabiliyor.
Kişisel Değerlendirmem
Dürüst olmak gerekirse, Açık olayım: Bu GA duyurusu, “tamam her şey hazır, yarın migration başlasın” demek değil. Daha çok, “ana akım senaryolar için artık güvenle ilerleyebilirsiniz, ama köşe vakaları için biraz bekleyin” demek. Microsoft’un burada izlediği yol bence fena değil; tüm mailbox tiplerini bir gecede teslim etmek yerine, önce en yüksek hacimli olanları toparlayip yayinladilar (ilk duyduğumda inanamadım). Evet, mantıklı.
Beklediğim kadar mi? Pek sayılmaz. Archive mailbox eksikliği, açık konuşayım, hâlâ can sıkıyor; çünkü gerçek hayatta işler tam da orada uzuyor (export, restore, uyumluluk derken konu dağılıyor). Ama doğru yönde atılmış bir adım bu, bunu da görmezden gelemem. Önümüzdeki 6-12 ayda public folder ve archive desteğinin de gelmesini umuyorum. Geldiği anda EWS’i artık kenara koyabiliriz — ki ben bunu 2007’den beri bekliyorum.
Sıkça Sorulan Sorular
Mailbox Import/Export API’leri ücretli mi?
Hayır, ekstra bir lisans almana gerek yok. Microsoft Graph’ın standart bir parçası olarak geliyor zaten. Ama şunu da söyleyeyim — çağrı sayısı Outlook resource limit’lerine bağlı, yanı throttling var. Yüksek hacimli işler yapıyorsan batch ve retry stratejisi kurmak şart.
EWS ne zaman tamamen kapanacak?
Şimdi, dürüst olmak gerekirse, Microsoft, EWS’in Exchange Online’da yavaş yavaş emekliye ayrılacağını açıkladı. Aslında son duyuruda Ekim 2026 civarı deniyordu, ama Microsoft bu tarihi daha önce de değiştirmişti. Bence en sağlıklısı resmî deprecation duyurusunu takipte tutmak — oradan anlık bilgi alırsın.
Archive mailbox için şu an ne yapmalıyım?
Bir bakıma, şunu fark ettim: Açıkçası şu an için archive mailbox senaryolarında hâlâ EWS ya da Compliance API gibi alternatiflere bağımlısın. Microsoft ileride archive desteği geleceğini söylüyor ama tarih vermiyor. Tecrübeme göre en mantıklı yaklaşım şu: kritik olmayan archive göçlerini beklet, önce primary. Shared mailbox migration’larından başla.
Preview döneminde yazdığım kod GA’da çalışacak mı?
Microsoft, API modelinin büyük ölçüde değişmediğini söylüyor. Yanı primary ve shared mailbox senaryolarında preview kodun büyük ihtimalle GA’da da sorunsuz çalışıyor. Yine de production’a geçmeden önce permission scope’larına ve response payload’larına bir göz at — hani küçük sürprizler olabiliyor.
Üçüncü parti backup ürünüm bu API’leri kullanıyor mu?
Bunu direkt vendor’una sormak en doğrusu. Mesela Veeam, AvePoint, CodeTwo gibi büyük ISV’ler preview döneminde testlere zaten başlamıştı. GA’dan sonra 3-6 ay içinde resmî destek duyurmaları bekleniyor. Bence vendor’ünün roadmap’ını şimdiden sorgulamak çok yerinde bir hamle.
Kaynaklar ve İleri Okuma
Microsoft 365 Developer Blog: GA Duyurusu
Microsoft Learn: Mailbox Import and Export APIs Resmî Dokümantasyonu
Microsoft Graph Throttling ve Outlook Resource Limits Kılavuzu
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
Yorum gönder