- Konu sahibi
- #1
SOAP API nedir?
SOAP API, uygulamaların XML tabanlı mesajlar aracılığıyla birbiriyle haberleşmesini sağlayan, kuralları ve mesaj yapısı standartlaştırılmış bir web servis yaklaşımıdır. SOAP ile bir servisin hangi işlemleri sunduğu, hangi verileri kabul ettiği ve başarılı ya da hatalı yanıtın nasıl döneceği tanımlanabilir. Özellikle kurumsal uygulamalarda, güçlü sözleşme ve standart hata yönetimi gerektiğinde tercih edilir.SOAP nasıl çalışır?
SOAP mesajı genellikle HTTP üzerinden gönderilir; ancak SOAP yalnızca HTTP'ye bağlı değildir. Mesaj XML tabanlıdır. Zorunlu Envelope, isteğe bağlı Header ve zorunlu Body yapısı bulunur; Fault ise gerektiğinde Body içinde taşınır:
- Envelope: Mesajın SOAP mesajı olduğunu belirten zorunlu dış kapsayıcıdır.
- Header: Kimlik doğrulama, işlem kimliği, yönlendirme veya başka üstveriler için kullanılan isteğe bağlı bölümdür.
- Body: İstenen işlem ve işlem parametrelerini içerir.
- Fault: SOAP hatasını anlatan, Body içinde yer alan hata elemanıdır; her mesajda bulunmaz.
SOAP servisinin sunduğu işlemler çoğunlukla WSDL adı verilen bir tanım belgesinde açıklanır. WSDL; servis adresini, operasyonları, parametre tiplerini, yanıt biçimlerini ve kullanılan mesaj sözleşmesini belirtir. Bu nedenle birçok programlama dili, WSDL'den istemci sınıflarını otomatik üretebilir.
Somut SOAP isteği ve yanıtı
Örneğin bir uygulama, müşteri numarasına göre müşteri bilgisini sorgulayan
GetCustomer adlı bir operasyon sunsun. SOAP 1.1 biçiminde sadeleştirilmiş istek şu yapıya sahip olabilir:
Kod:
<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:m="urn:example:customer">
<soap:Body>
<m:GetCustomer>
<m:CustomerId>42</m:CustomerId>
</m:GetCustomer>
</soap:Body>
</soap:Envelope>Servis işlemi başarıyla yürütürse gövde içinde benzer şekilde yapılandırılmış bir yanıt döner:
Kod:
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:m="urn:example:customer">
<soap:Body>
<m:GetCustomerResponse>
<m:Customer>
<m:Id>42</m:Id>
<m:Name>Örnek Müşteri</m:Name>
</m:Customer>
</m:GetCustomerResponse>
</soap:Body>
</soap:Envelope>Buradaki
urn:example:customer değeri, XML ad alanını temsil eden varsayımsal bir tanımlayıcıdır. Gerçek serviste eleman adları, ad alanları ve veri tipleri WSDL ile aynı olmalıdır. Yalnızca XML'i yaklaşık olarak yazmak yeterli değildir; sözleşmedeki ad, sıra, tip ve zorunluluk kuralları da karşılanmalıdır.SOAP API kullanırken izlenecek yol
- WSDL'yi inceleyin veya istemci üretin. Önce servis adresini, operasyon adlarını, zorunlu alanları ve veri tiplerini belirleyin. Uygulamanızın dili destekliyorsa WSDL'den istemci üretmek, XML'i elle oluşturmaya göre daha az hata üretir.
- SOAP sürümünü ve iletişim biçimini doğrulayın. SOAP 1.1 ile SOAP 1.2 farklı zarf ad alanları kullanır. HTTP üzerinde SOAP 1.1 genellikle text/xml, SOAP 1.2 application/soap+xml kullanır; sürüm ve action gereksinimini servis belgesinden doğrulayın. İstemci ve sunucu aynı sürümü kullanmalıdır.
- Kimlik doğrulama gereksinimini uygulayın. Bazı servisler HTTP kimlik doğrulaması, bazıları SOAP Header içinde WS-Security bilgisi veya başka bir kurumsal mekanizma kullanır. Gerekli alanları WSDL ve servis dokümanındaki sözleşmeye göre gönderin.
- Başarılı yanıtı ve Fault yanıtını ayrı işleyin. HTTP isteğinin ulaşmış olması işlemin başarılı olduğu anlamına gelmez. XML içindeki SOAP Fault bilgisini ayrıştırın; hata kodunu ve güvenli özetini kaydedin. Kimlik bilgisi veya kişisel veri içerebilen tam yanıtı filtresiz günlüğe yazmayın.
- Test isteğini gerçek uygulama akışına bağlayın. Önce sabit ve geçerli bir örnekle yanıt şemasını doğrulayın; ardından parametreleri kullanıcı veya veritabanı verilerinden üretin. Yanıttaki zorunlu alanlar yoksa uygulamanızın bunu hata olarak ele almasını sağlayın.
SOAP ile REST arasındaki temel fark
Her iki yaklaşım da uygulamalar arasında veri alışverişi sağlar; ancak seçim, servisin sözleşme ve kurumsal gereksinimlerine göre yapılmalıdır.
| Özellik | SOAP | REST |
|---|---|---|
| Mesaj biçimi | XML tabanlı standart zarf | Çoğunlukla JSON; farklı biçimler de mümkündür |
| Sözleşme | Çoğunlukla WSDL ile sözleşme; SOAP için WSDL zorunlu değildir | Genellikle kaynak ve HTTP işlemleri üzerinden tanımlanır |
| Hata biçimi | SOAP Fault yapısı | HTTP durum kodu ve uygulamaya özgü gövde |
| Tercih nedeni | Kurumsal sözleşme, güvenilirlik ve standart mesaj eklentileri | Daha yalın, kaynak odaklı ve tarayıcı/istemci dostu API tasarımı |
Bu karşılaştırma, SOAP'ın her durumda daha iyi veya REST'in her durumda daha basit olduğu anlamına gelmez. Mevcut bir kurumsal servis WSDL ve SOAP tabanlıysa istemciyi buna göre kullanmak gerekir. Yeni ve küçük bir HTTP servisi tasarlanıyorsa veri biçimi, istemci çeşitliliği, sözleşme ihtiyacı ve mevcut altyapı birlikte değerlendirilmelidir.
Sık yapılan hatalar
En yaygın hata, SOAP sürümünü kontrol etmeden hazır bir XML örneğini kullanmaktır. Zarf ad alanı veya HTTP içerik türü yanlışsa sunucu isteği geçerli bir SOAP mesajı olarak kabul etmeyebilir. Bir başka hata, WSDL'deki ad alanlarını ve büyük-küçük harf duyarlılığını değiştirmektir. XML geçerli olsa bile sözleşmeye uymayan alanlar operasyonun reddedilmesine yol açabilir.
Ayrıca yalnızca HTTP durum koduna bakmak da yanlıştır. Servis uygulama seviyesinde hata verdiğinde ayrıntı SOAP Fault içinde bulunabilir. Son olarak, istemci kütüphanesinin otomatik ürettiği XML'i incelemeden üretime almak; tarih, ondalık sayı, boş değer ve karakter kodlaması gibi alanlarda beklenmeyen uyumsuzluklara neden olabilir.
