API Rehberi: REST ve SOAP Mimarileri, Avantajları ve Dezavantajları
Mustafa Kürşad BAŞER
API Nedir?
REST ve SOAP’a girmeden önce bir adım geriye gidip API kavramını yerine oturtalım.
API, iki yazılımın birbiriyle konuşmak için üzerinde anlaştığı sözleşme. Karşı tarafın kodunu görmezsiniz, veri tabanına da dokunmazsınız; sadece "şu adrese şu formatta sorarsan şu cevabı alırsın" garantisini alırsınız. Hava durumu gösteren bir uygulamanın meteoroloji verisini nasıl aldığını düşünün: ölçüm istasyonlarına bağlanmıyor, bir API çağırıyor.
REST Mimarisi Nedir?
REST’i (Representational State Transfer) Roy Fielding 2000 yılındaki doktora tezinde tanımladı. Baştan bir yanlış anlamayı düzeltelim: REST bir protokol değil, mimari bir tarz. Yani indirip kuracağınız bir şey yok, uyacağınız bir dizi kısıt var. HTTP’yi zaten bildiğiniz gibi kullanmanızı, sunucuda oturum durumu tutmamanızı ve her şeyi kaynak olarak modellemenizi istiyor.
İşleyişi basit. Her varlık bir kaynaktır ve bir adresi (URI) vardır. Ne yapmak istediğinizi adres değil, HTTP metodu söyler. /kullanicilar/42 adresine GET atarsanız okursunuz, DELETE atarsanız silersiniz. Adres aynı kalır, fiil değişir.
Bu yaklaşımın en büyük kazancı, ortada öğrenilecek yeni bir katman olmaması. Tarayıcı, mobil uygulama, curl ya da başka bir sunucu; HTTP konuşan her şey bir REST API ile konuşabilir. Sunucuda oturum tutulmadığı için de trafiği birden çok makineye dağıtmak kolaylaşır.
Bu kısıtlara uyan servislere RESTful deniyor. Pratikte pek çok API kendine RESTful dese de kısıtların bir kısmını uygulamaz; sektörde kabul gören esnek bir kullanım bu.
HTTP metotları çoğu zaman CRUD işlemlerine karşılık gelir: POST oluşturur, GET okur, PUT veya PATCH günceller, DELETE siler. Bir blog API’sinde /yazilar adresine POST atmak yeni yazı açar, /yazilar/7 adresine GET atmak o yazıyı getirir.
GET isteklerinin yan etkisiz olması da önemli bir ayrıntı. Yan etkisi olmayan bir isteği tarayıcı, ara sunucu ya da CDN gönül rahatlığıyla önbelleğe alabilir. REST’in ölçeklenme avantajının büyük kısmı bu tek kuraldan geliyor.
SOAP Mimarisi Nedir?
SOAP ise mimari bir tarz değil, protokolün ta kendisi. Adı başlangıçta Simple Object Access Protocol açılımından geliyordu, ancak 1.2 sürümüyle bu açılım resmen bırakıldı ve kısaltma öylece kaldı. Mesajları XML olarak kodluyor ve her mesajı bir zarfa (envelope) sarıyor: başlık kısmında kimlik ve yönlendirme bilgileri, gövde kısmında asıl veri. REST’ten farklı olarak taşıyıcıya bağımlı değil; HTTP dışında SMTP ya da doğrudan TCP üzerinden de gidebilir.
SOAP’ın asıl gücü sözleşmede. Servis, sunduğu işlemleri ve veri tiplerini WSDL adında bir XML dosyasında tarif eder. Elinizde bu dosya varsa çoğu dilin araç zinciri istemci kodunu sizin için üretir; hangi alanın hangi tipte olduğu tartışmaya kapalıdır. REST tarafında bu kesinliği elde etmek için OpenAPI gibi ayrı bir tanım dosyası yazmanız gerekir.
REST ve SOAP Arasındaki Farklar Nelerdir?
İkisini yan yana koyduğumuzda ilk fark kategorik: REST bir mimari tarz, SOAP bir protokol. Bu yüzden karşılaştırma hiçbir zaman tam elma elmaya olmuyor. Yine de pratikte ayrıştıkları noktalar şunlar:
Yük boyutu: SOAP her mesaja XML zarfı ve başlık ekler, dolayısıyla aynı veri REST’teki JSON karşılığından belirgin biçimde daha büyük gider.
Veri formatı: REST format konusunda serbesttir, JSON en yaygını ama XML de olabilir. SOAP’ta ise seçenek yok, mesaj XML’dir.
Performans: Küçük yük ve önbelleklenebilir GET istekleri REST’i öne çıkarır. SOAP’ta XML ayrıştırma maliyeti ve önbellek dostu olmayan yapı, yüksek trafikte hissedilir.
Güvenlik: Bu maddeyi "SOAP daha güvenli" diye özetlemek yanlış olur. Fark, güvenliğin hangi katmanda kurulduğu. SOAP, WS-Security ile mesajın kendisini imzalayıp şifreleyebilir; mesaj birkaç ara düğümden geçse bile korunur. REST tarafında güvenlik genellikle taşıma katmanında, yani HTTPS üzerinde kurulur ve kimlik doğrulama için OAuth 2.0 ya da JWT kullanılır. Doğru kurulduğunda ikisi de güvenlidir.
Araç ihtiyacı: REST için tarayıcı ya da curl yeterli. SOAP’ta WSDL okuyup istemci üreten bir araç zincirine ihtiyaç duyarsınız; bu, kurumsal ortamlarda avantaj, hızlı prototipte yüktür.
REST Mimarisinin Avantajları
Ölçeklenebilir: Sunucu istekler arasında durum tutmadığı için trafiği yeni makinelere dağıtmak, önüne yük dengeleyici koymak kadar basit.
Platform bağımsız: HTTP konuşabilen her istemci REST API ile konuşabilir. Ek kütüphane şartı yok.
Hafif: JSON yükü XML zarfına kıyasla küçük kalır. Mobil gibi bant genişliğinin dar olduğu ortamlarda bu fark hissedilir.
Öğrenmesi kolay: Adres ve HTTP metodu bildikten sonra ayrıca öğrenilecek bir katman yok. Yeni bir geliştirici API’yi tarayıcıda gezerek çözebilir.
Önbelleklenebilir: Yan etkisiz GET istekleri tarayıcı, ara sunucu ve CDN tarafından önbelleğe alınabilir. Sunucuya hiç ulaşmayan istek en hızlı istektir.
REST Mimarisinin Dezavantajları
Hazır güvenlik standardı yok: SOAP’taki WS-Security gibi kutudan çıkan bir mesaj güvenliği katmanı bulunmuyor. HTTPS, kimlik doğrulama ve yetkilendirmeyi siz kurarsınız. Esneklik burada aynı zamanda sorumluluk demek.
Resmi sözleşme yok: SOAP’ın WSDL’i gibi zorunlu bir tanım dosyası olmadığı için, istemci ile sunucu arasındaki anlaşma dokümantasyona kalır. OpenAPI bu boşluğu doldurur ama kullanmak size bağlıdır.
Fazla ya da eksik veri: Uç noktalar sabit olduğu için istemci çoğu zaman ihtiyacından fazlasını alır, bazen de tek ekran için birkaç çağrı yapmak zorunda kalır. GraphQL tam olarak bu sıkıntıdan doğdu.
Sürüm yönetimi: Yanıt yapısını değiştirdiğinizde eski istemciler kırılır. Yaygın çözüm adrese sürüm koymak (/v1/kullanicilar), ama bu da iki sürümü bir süre birlikte yaşatmak anlamına gelir.
JSON ve XML Nedir?
JSON (JavaScript Object Notation) ve XML (eXtensible Markup Language), servisler arasında veri taşımak için kullanılan iki format. İkisi de hem insan hem makine tarafından okunabiliyor. JSON veriyi anahtar-değer çiftleriyle tutuyor, XML ise etiketlerle sarmalayıp ağaç kuruyor. Yaygın bir yanılgıyı düzeltelim: JSON yalnızca basit yapılar için uygun değildir, iç içe nesne ve dizileri gayet taşır. Asıl fark başka yerde. XML’in isim uzayı, öznitelik, yorum satırı ve XSD ile şema doğrulaması gibi araçları var. JSON daha az yer kaplıyor ve JavaScript tarafında ek bir ayrıştırma adımı gerektirmiyor. Bu yüzden web API’lerinde JSON, kurumsal entegrasyonlarda XML ağır basıyor.
Sonuç
İkisi arasındaki gerilim aslında tek bir eksende: katılık mı esneklik mi? SOAP her şeyi önden sözleşmeye bağlar, karşılığında ağırlık ve araç bağımlılığı getirir. REST size yol verir, karşılığında sözleşmeyi ve güvenlik kurgusunu sizin kurmanızı bekler.
Bugün sıfırdan bir servis yazıyorsanız, özel bir sebebiniz yoksa REST tarafındasınız demektir. SOAP hala ayakta ve bankacılık, sigorta, telekom gibi alanlarda yaygın; oralarda mesaj seviyesinde imza, resmi sözleşme ve işlem güvencesi gibi ihtiyaçlar SOAP’ı yerinde tutuyor. Bir de basitçe eski sistemlerin öyle yazılmış olması var.
Karar verirken kendinize iki soru sorun. Mesajın kendisinin imzalanması ya da şifrelenmesi gerekiyor mu? Karşı taraf size makinece okunabilir bir sözleşme dayatıyor mu? İkisine de hayır diyorsanız REST fazlasıyla yeterli.
Referanslar
Mustafa Kürşad Başer
Senior Software Engineer
A passionate software engineer who enjoys creating elegant solutions to complex problems. Beyond coding, I am deeply interested in exploring the intersections of technology, art, and human consciousness.
