Elinize bir SOAP uç noktası ulaştığında hedefiniz nettir: çağrıyı doğru XML zarfıyla göndermek, sözleşmeye uygun yanıtı doğrulamak ve bu kontrolü tekrarlanabilir hâle getirmek. Bu; eski bir döviz dönüştürücüsü, iş ortağının .NET tabanlı sipariş servisi veya hâlâ WS-Security kullanan kurumsal bir hizmet olabilir. SOAP, REST'ten farklı olarak tam bir XML zarfı, doğru Content-Type değeri ve işlemleri tanımlayan bir WSDL sözleşmesi gerektirir.
Apidog, REST, GraphQL ve gRPC ile birlikte SOAP ve Web Hizmeti isteklerini de yönetir. Bu rehberde iki uygulama yolunu kullanacaksınız:
- SOAP isteğini XML zarfını kendiniz oluşturarak göndermek
- WSDL dosyasını içe aktararak uç noktaları ve ortamı otomatik oluşturmak
Protokollerin kullanım alanlarını karşılaştırmak için REST, GraphQL, gRPC ve SOAP rehberine bakabilirsiniz. SOAP zarfının resmi tanımı için W3C SOAP spesifikasyonunu kullanın.
SOAP nedir ve neden farklı bir işleme ihtiyacı vardır?
SOAP (Basit Nesne Erişim Protokolü), farklı platformların ve programlama dillerinin XML tabanlı bir sözleşme üzerinden haberleşmesini sağlar. Örneğin bir Java istemcisi, .NET üzerinde çalışan bir servisle ortak WSDL sözleşmesine göre iletişim kurabilir.
SOAP isteklerini test ederken şu üç noktaya odaklanın:
- Mesaj biçimi XML'dir. İstek ve yanıtlar yapılandırılmış XML belgeleridir. XML sözdizimi için MDN XML referansını kullanabilirsiniz.
- Taşıma genellikle HTTP/HTTPS'dir. SOAP başka taşıma protokollerini de destekleyebilir.
- Sözleşme katıdır. İşlem adı, ad alanı, parametre yapısı ve zarf biçimi servis beklentisiyle eşleşmelidir.
Bu nedenle SOAP çağrısında yalnızca bir URL'ye JSON göndermek yeterli değildir. Doğru Content-Type, SOAP zarfı ve XML yanıtını doğrulayacak kontroller gerekir. Zarf ve XML yapısı hakkında daha fazla ayrıntı için SOAP API'leri ve XML rehberine bakın.
Başlamadan önce
SOAP veya Web Hizmeti isteği göndermek için Apidog sürümünüzün 2.1.31 veya üzeri olması gerekir.
Başlamadan önce şunları hazırlayın:
- SOAP uç noktası URL'si
- Çağıracağınız işlem adı
- İşlem parametreleri
- Varsa
.wsdlveya.xmlbiçimindeki WSDL dosyası
WSDL, işlemleri, parametreleri ve servis adresini tanımlar. Resmî yapı için WSDL 2.0 spesifikasyonuna başvurabilirsiniz.
Yol A: SOAP isteğini elle gönderme
Bu yaklaşımı, elinizde uç nokta URL'si ve işlem şeması olduğunda kullanın.
Adım 1: Content-Type başlığını ayarlayın
SOAP isteklerinde Content-Type değerini manuel girmeniz gerekir. Yaygın seçenekler:
text/xml; charset=utf-8
application/soap+xml
Genel kural:
| SOAP sürümü | Yaygın Content-Type
|
|---|---|
| SOAP 1.1 | text/xml; charset=utf-8 |
| SOAP 1.2 | application/soap+xml |
WSDL veya servis dokümantasyonundaki binding bilgisini kontrol edin. İçerik türü hatası alırsanız servisinizin beklediği diğer değeri deneyin.
Apidog'da isteğin Headers bölümüne örneğin şunu ekleyin:
Content-Type: text/xml; charset=utf-8
Adım 2: Gövdeyi XML olarak ayarlayın
İstek gövde formatını xml olarak seçin. Ardından SOAP zarfını ekleyin.
Aşağıdaki örnek, herkese açık NumberToWords işlemini çağırır ve ubiNum parametresine 1234 değerini gönderir:
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:web="http://www.dataaccess.com/webservicesserver/">
<soap:Body>
<web:NumberToWords>
<web:ubiNum>1234</web:ubiNum>
</web:NumberToWords>
</soap:Body>
</soap:Envelope>
Bu yapıdaki kritik alanlar:
-
soap:Envelope: SOAP mesajının kök düğümü -
soap:Body: Gerçek servis çağrısını taşıyan bölüm -
web:NumberToWords: Çağrılan işlem -
web:ubiNum: İşleme iletilen parametre -
xmlns:web: Servisin beklediği ad alanı
Ad alanını tahmin etmeyin. Doğru namespace değerini WSDL'den veya servis dokümantasyonundan alın.
Adım 3: İsteği gönderin ve XML yanıtını doğrulayın
Başlık ve XML gövdesi hazır olduğunda isteği gönderin. Başarılı bir yanıt yine SOAP zarfı içinde döner:
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<m:NumberToWordsResponse xmlns:m="http://www.dataaccess.com/webservicesserver/">
<m:NumberToWordsResult>one thousand two hundred and thirty four</m:NumberToWordsResult>
</m:NumberToWordsResponse>
</soap:Body>
</soap:Envelope>
Yanıtı kontrol ederken en az şunları doğrulayın:
- SOAP zarfı mevcut mu?
- Beklenen yanıt düğümü mevcut mu?
Örneğin:
NumberToWordsResponse - Sonuç düğümü beklenen değeri içeriyor mu?
Örneğin:
NumberToWordsResult
Ek çalışan SOAP örnekleri ve yapılandırma referansı için webservice.apidog.io adresini kullanabilirsiniz.
Gerçek bir entegrasyonda aynı deseni uygularsınız:
-
NumberToWordsyerineConvertCurrencyçağırın. -
fromCurrency,toCurrencyveamountparametrelerini XML düğümleri olarak gönderin. - Dönen dönüştürülmüş değeri doğrulayın.
Veya sipariş servisi için:
-
GetOrderStatusişlemini çağırın. -
orderIdparametresini iletin. - Dönen durum değerinin izin verilen değerlerden biri olduğunu doğrulayın.
Temel akış değişmez:
Header ayarla → XML zarfını oluştur → Gönder → XML yanıtını doğrula
Yol B: WSDL içe aktararak uç noktaları oluşturma
Birden fazla SOAP işlemiyle çalışıyorsanız zarfları tek tek yazmak yerine WSDL'yi içe aktarın. WSDL; servis işlemlerini, parametreleri ve adres bilgisini içerir. Apidog bu tanımları okuyarak uç noktaları oluşturur.
İzlenecek adımlar:
- Ayarlar bölümünü açın.
- Veri İçe Aktar seçeneğini seçin.
-
WSDLseçeneğini seçin. -
.wsdlveya.xmldosyanızı yükleyin. - Ayrıştırılan API uç noktalarının önizlemesini inceleyin.
- Ortamlar sekmesinde servis adresini doğrulayın.
-
Onayladüğmesine tıklayın. - Sağ üstten içe aktarılan ortamı seçin.
- Bir istek gönderin.
Servis adresini onaylamadan önce kontrol edin
WSDL içindeki servis adresi, içe aktarılan isteklerin kullanacağı hedef uç noktadır. Bu adres:
- hazırlık ortamına,
- eski bir ortama,
- yer tutucu bir URL'ye
işaret ediyor olabilir.
Bu nedenle Onayla düğmesine basmadan önce Ortamlar sekmesindeki adresi kontrol edin.
Doğru ortamı seçin
İçe aktarma işlemi ortamı otomatik oluşturur. Ancak isteği göndermeden önce sağ üstte bu ortamın seçili olduğundan emin olun.
Ortam seçilmezse temel URL uygulanmaz ve istek başarısız olabilir.
İçe aktardıktan sonra her SOAP işlemi çağrılabilir bir uç nokta olarak görünür. Yanıt XML'ini, elle oluşturduğunuz istekteki gibi doğrulayabilirsiniz.
Başka bir araçtan tam proje taşıyorsanız SOAP projelerini içe aktarma rehberini izleyin.
WSDL içe aktarma için belgelenen yöntem
.wsdlveya.xmldosyası yüklemektir. URL ile içe aktarma veya WSDL metnini doğrudan yapıştırma belgelenmemiştir.
SoapUI'dan geçiş
SOAP testleriniz SoapUI'da bulunuyorsa testleri sıfırdan oluşturmadan WSDL dosyanızı Apidog'a aktarabilirsiniz.
İzlenecek yaklaşım:
- SoapUI projenizde kullandığınız WSDL'yi dışa aktarın veya mevcut dosyayı alın.
- WSDL'yi Apidog'a içe aktarın.
- Oluşturulan ortamın servis adresini doğrulayın.
- İşlemleri çağırın ve XML yanıt doğrulamalarını ekleyin.
Bu yaklaşım, SOAP servislerini REST uç noktaları ve test senaryolarıyla aynı çalışma alanında tutmanızı sağlar. Aktarılabilir içerikler ve iş akışı farkları için Apidog ve SoapUI karşılaştırmasını inceleyin.
Doğrulamalar ve test senaryoları
Başarılı bir çağrı, uç noktanın yanıt verdiğini gösterir. Test ise yanıtın sözleşmeye uygun olduğunu kanıtlar.
SOAP yanıtlarınızda şu kontrolleri uygulayın:
- Beklenen yanıt işlem düğümünün varlığını doğrulayın.
- Sonuç düğümünü okuyun.
- Sonucu beklenen değer veya kuralla karşılaştırın.
- Hata durumlarında SOAP Fault düğümü olup olmadığını kontrol edin.
Örnek doğrulama kuralları:
| Servis türü | Doğrulama |
|---|---|
| Döviz dönüşümü | Sonucun sayısal ve beklenen aralıkta olması |
| Sipariş durumu | Durumun izin verilen değerlerden biri olması |
| Müşteri sorgusu | Müşteri kimliği ve temel alanların dönmesi |
| Hesaplama işlemi | Sonucun beklenen hesaplama sonucuyla eşleşmesi |
Birden fazla çağrıyı zincirlemek için test senaryosu oluşturun. Örneğin:
Sipariş oluştur → orderId değerini çıkar → Sipariş durumunu sorgula → Durumu doğrula
Değerleri bir istekten diğerine aktarma adımları için Apidog ile test senaryosu yazma rehberine bakın.
Bu desen protokolden bağımsızdır. Aynı senaryoda SOAP çağrılarını REST veya GraphQL istekleriyle birlikte kullanabilirsiniz.
WS-Security kullanan uç noktalar
Güvenli SOAP servisleri sıklıkla WS-Security kullanır. Bu durumda güvenlik bilgileri SOAP zarfının Header bölümünde yer alır.
Genel yapı şöyledir:
<soap:Envelope>
<soap:Header>
<wsse:Security>
<!-- Güvenlik bilgileri -->
</wsse:Security>
</soap:Header>
<soap:Body>
<!-- İşlem çağrısı -->
</soap:Body>
</soap:Envelope>
Gönderim akışı değişmez:
- Uygun
Content-Typedeğerini ayarlayın. - WS-Security başlığı dahil tüm SOAP zarfını XML gövdesine ekleyin.
- İsteği gönderin.
- XML yanıtı veya SOAP Fault yanıtını doğrulayın.
İş akışını Apidog CLI ile otomatikleştirin
SOAP veya WSDL ile içe aktardığınız istekleri test senaryoları olarak kaydettiğinizde, Apidog CLI ile bunları komut satırından çalıştırabilirsiniz.
Node.js v16 veya üzeriyle kurulumu yapın:
npm install -g apidog-cli
apidog login --with-token <YOUR_ACCESS_TOKEN>
Ardından kaydedilmiş bir senaryoyu belirli bir ortamda çalıştırın:
apidog run --access-token $APIDOG_ACCESS_TOKEN -t <scenario_id> -e <env_id> -r cli
Parametreler:
| Parametre | Açıklama |
|---|---|
-t |
Test senaryosu kimliği |
-e |
Ortam kimliği |
-r |
Raporlayıcı |
Birden fazla raporlayıcıyı virgülle ayırabilirsiniz:
-r cli,html,junit
Belgeler, CLI'ın kaydedilmiş test senaryolarını ve süitlerini çalıştırdığını doğrular. Ancak SOAP adımlarına dayalı senaryolar için başsız yürütme davranışı ayrıca belirtilmemiştir. Bu nedenle CI kullanımında SOAP'a özel yürütmeyi varsaymadan önce kendi projenizde doğrulama yapın.
Pipeline entegrasyonu için Apidog CLI CI/CD kılavuzunu kullanın.
Sıkça Sorulan Sorular
SOAP isteği için hangi Content-Type değerini kullanmalıyım?
Şu değerlerden birini kullanın:
text/xml; charset=utf-8
veya:
application/soap+xml
SOAP 1.1 uç noktaları genellikle text/xml; charset=utf-8, SOAP 1.2 uç noktaları ise application/soap+xml bekler. Kesin değeri WSDL veya servis dokümantasyonundan kontrol edin.
Apidog'da SOAP test etmek için ücretli plana ihtiyacım var mı?
Belgelenen teknik gereksinim Apidog'un 2.1.31 veya üzeri bir sürümde olmasıdır. SOAP veya WSDL desteği için ayrıca bir katman sınırlaması ya da kendi kendine barındırma kısıtlaması belirtilmemiştir.
WSDL'yi URL üzerinden içe aktarabilir miyim?
Belgelenen yöntem .wsdl ve .xml dosyalarını yüklemektir. URL üzerinden veya WSDL metnini yapıştırarak içe aktarma belgelenmemiştir.
SOAP ve REST API'lerini aynı projede nasıl test ederim?
SOAP işlemlerini, REST uç noktalarını ve GraphQL çağrılarını aynı çalışma alanında tutabilirsiniz. Test senaryolarında bu istekleri sırayla çalıştırıp değerleri adımlar arasında aktarabilirsiniz.
GraphQL testleri için Apidog'da GraphQL API'lerini test etme rehberini inceleyin.
WSDL ile içe aktardığım istekler neden yanlış sunucuya gidiyor?
İki yaygın neden vardır:
- İçe aktarma sırasında Ortamlar sekmesindeki servis adresi yanlıştı.
- İsteği göndermeden önce sağ üstten içe aktarılan ortamı seçmediniz.
WSDL'yi yeniden içe aktarın, servis adresini onaylamadan önce doğrulayın ve doğru ortamın aktif olduğundan emin olun.
Sonuç
SOAP testleri için ayrı bir eski araç kullanmak zorunda değilsiniz. Apidog ile iki yol izleyebilirsiniz:
-
Elle gönderme:
Content-Typeayarlayın, XML zarfını oluşturun, isteği gönderin ve XML yanıtını doğrulayın. - WSDL içe aktarma: WSDL dosyasını yükleyin, servis adresini kontrol edin, ortamı seçin ve oluşturulan uç noktaları kullanın.
Her iki yaklaşım da SOAP servisinizin sözleşmeye uygun çalıştığını tekrarlanabilir şekilde kontrol etmenizi sağlar. Apidog'u indirin, WSDL'nizi içe aktarın ve eski SOAP servislerinizi API yüzeyinizin geri kalanıyla aynı test akışına dahil edin.
Top comments (0)