SOAP API Testi Online: Araçlar ve Çalışan Bir Örnek

SOAP ortadan kalkmadı. Bankacılık sistemleri, ödeme ağ geçitleri, devlet hizmetleri ve eski kurumsal platformlar hala SOAP uç noktaları sunuyor ve birilerinin bunları test etmesi gerekiyor. Kariyerinizi REST ve JSON üzerine kurduysanız, bir SOAP hizmeti size yabancı gelebilir. Protokol daha katıdır, yükler XML'dir ve sözleşme ayrı bir WSDL dosyasında bulunur.

İyi haber şu ki, çevrimiçi bir SOAP API'yi test etmek, ondan ne istediğini bir kez anladığınızda zor değildir. Bu kılavuz, SOAP testinin REST testinden nasıl farklılaştığını açıklar, gerçek bir isteği adım adım inceler ve SOAP'ı sorunsuz bir şekilde yöneten çevrimiçi araçları kapsar.

SOAP testi neden farklıdır?

REST bir tarzdır. SOAP kurallara sahip bir protokoldür. Bu ayrım, onu nasıl test ettiğinize dair her şeyi şekillendirir.

Bir SOAP mesajı her zaman bir zarfa sarılmış bir XML belgesidir. Zarf, kimlik doğrulama veya yönlendirme gibi meta veriler için bir başlığa ve gerçek işlemi ve parametrelerini barındıran bir gövdeye sahiptir. Sadece gevşek bir JSON nesnesi gönderemezsiniz. Yapı zorunludur ve hatalı biçimlendirilmiş bir zarf, mantığınız çalışmadan önce reddedilir. SOAP ayrıca, yalnızca veri okuyan işlemler için bile neredeyse her zaman HTTP POST üzerinden iletilir ve genellikle text/xml veya application/soap+xml olmak üzere belirli bir Content-Type bekler.

En büyük pratik fark WSDL'dir. WSDL veya Web Hizmetleri Açıklama Dili dosyası, hizmetin sunduğu her işlemi, her isteğin ve yanıtın tam şeklini ve uç nokta adresini listeleyen, makine tarafından okunabilir bir sözleşmedir. REST nadiren bu kadar katı bir şey sunar. SOAP'ı test ettiğinizde, WSDL sizin haritanızdır. İyi bir çevrimiçi SOAP test aracı, WSDL'yi okur ve sizin için istek şablonları oluşturur, böylece zarfları elle ezbere yazmazsınız. Daha geniş sözleşme resmini istiyorsanız, API sözleşme testi hakkındaki notlarımız, neden katı bir sözleşmenin bir varlık olduğunu açıklar.

Gerçek bir SOAP isteği neye benzer?

İşte bir para birimi dönüştürme hizmetine karşı gerçekçi bir SOAP isteği. Zarfı, ad alanı bildirimlerini ve gövdeye yerleştirilmiş işlemi fark edin.

POST /CurrencyService.asmx HTTP/1.1
Host: rates.example.com
Content-Type: text/xml; charset=utf-8
SOAPAction: "https://rates.example.com/ConvertAmount"

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
               xmlns:cur="https://rates.example.com/">
  <soap:Header>
    <cur:AuthToken>e9f2a1c7-4b8d-4c2a-9f31-7d6e5a4b3c21</cur:AuthToken>
  </soap:Header>
  <soap:Body>
    <cur:ConvertAmount>
      <cur:FromCurrency>USD</cur:FromCurrency>
      <cur:ToCurrency>EUR</cur:ToCurrency>
      <cur:Amount>250.00</cur:Amount>
    </cur:ConvertAmount>
  </soap:Body>
</soap:Envelope>

Yanıt aynı şekilde sarılmış olarak geri gelir:

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
               xmlns:cur="https://rates.example.com/">
  <soap:Body>
    <cur:ConvertAmountResponse>
      <cur:ConvertAmountResult>231.45</cur:ConvertAmountResult>
    </cur:ConvertAmountResponse>
  </soap:Body>
</soap:Envelope>

İki detay insanları yanıltır. SOAPAction HTTP başlığı birçok hizmet tarafından gereklidir ve işlemle eşleşmelidir, aksi takdirde bir hata (fault) alırsınız. Bir şeyler başarısız olduğunda, SOAP düzenli bir mesajla HTTP 400 döndürmez. Bunun yerine, gövde içinde bir <soap:Fault> öğesiyle HTTP 200 döndürür. Çağrının gerçekten başarılı olup olmadığını anlamak için testinizin gövdeyi ayrıştırması gerekir. Yalnızca durum kodunu kontrol etmek yeterli değildir, bu da yapılandırılmış API doğrulamalarının burada REST'e göre neden daha önemli olduğunun bir nedenidir.

SOAP API'lerini test etmek için çevrimiçi araçlar

Apidog

Apidog, REST, GraphQL ve WebSocket ile birlikte SOAP'ı tek bir yerde yönetir. Bir WSDL'yi içe aktarırsınız ve istek yapısını oluşturur, böylece zarfları elle oluşturmak zorunda kalmazsınız. XML öğeleri üzerinde doğrulamalar ekleyebilir, istekleri bir senaryoya zincirleyebilir ve tümünü otomatik bir paket olarak çalıştırabilirsiniz. Aynı zamanda API'leri tasarladığı ve taklit ettiği için, gerçek hizmet hazır olmadan önce bir SOAP yanıtını taklit edebilirsiniz. Ücretsiz katmanda SOAP hizmetlerini test etmek için Apidog'u indirin.

SoapUI

SoapUI, orijinal SOAP test aracıdır ve hala en kapsamlısıdır. Bir WSDL'ye işaret ettiğinizde, her işlemle birlikte bir proje oluşturur. Açık kaynak sürümü, fonksiyonel ve veri odaklı SOAP testleri için ücretsiz ve güçlüdür. Daha ağır bir Java masaüstü uygulamasıdır ve en gelişmiş raporlama özellikleri ücretli ReadyAPI katmanında bulunur. Daha yakından bakmak için SoapUI'nin ne olduğunu ve nasıl çalıştığını inceleyin.

Postman

Postman, SOAP istekleri gönderebilir. Gövdeyi ham XML olarak ayarlarsınız, Content-Type ve SOAPAction başlıklarını manuel olarak eklersiniz ve zarfınızı yapıştırırsınız. Çalışır, ancak Postman bir WSDL'yi ayrıştırmaz, bu yüzden zarfları kendiniz oluşturmanız gerekir. Tek seferlik bir kontrol için uygun olsa da, büyük bir SOAP yüzeyi için daha az rahattır.

Tarayıcı tabanlı SOAP test araçları

Birkaç hafif web aracı, bir WSDL URL'sini yapıştırmanıza ve tarayıcı sekmesinden istekler göndermenize olanak tanır. Kurulum gerektirmeden hızlı bir doğrulama için kullanışlıdırlar. Sınırlar hızla ortaya çıkar: zayıf doğrulama desteği, çok az otomasyon veya hiç otomasyon olmaması ve gerçek bir test paketini düzenlemenin bir yolu olmaması. Bunları bir uç noktanın aktif olduğunu doğrulamak için kullanın, bir regresyon paketi oluşturmak için değil.

Hızlı bir SOAP test iş akışı

1. WSDL'yi edinin. Çoğu SOAP hizmeti, uç nokta URL'sine ?wsdl ekleyerek bunu sunar. Açın ve yüklendiğini doğrulayın.
2. WSDL'yi aracınıza aktarın. Apidog ve SoapUI buradan istek şablonları oluşturur. Bu, en büyük zaman tasarrufu sağlayan faktördür.
3. İşlem parametrelerini doldurun. Gerçek değerler kullanın. Bir para birimi dönüşümünü gerçek bir miktar ve geçerli para birimi kodlarıyla test edin.
4. Başlıkları ayarlayın. Content-Type ve gerektiğinde SOAPAction'ı doğrulayın. Eksik bir SOAPAction, açıklanamayan bir hatanın en yaygın nedenidir.
5. Gövdeyi gönderin ve inceleyin. HTTP durumunda durmayın. Yanıt gövdesini açın ve <soap:Fault> olup olmadığını kontrol edin.
6. Doğrulamalar ekleyin. Belirli bir öğenin var olduğunu ve beklenen değeri tuttuğunu doğrulayın. Ardından, akışınız gerektiriyorsa bir takip çağrısı zincirleyin.

Bunları sürdürülebilir bir set halinde düzenlemek için, API otomasyonu için test paketleri oluşturma kılavuzumuz doğrudan SOAP çalışmalarına uygulanabilir.

SOAP hataları ve bunlar üzerinde nasıl doğrulama yapılır?

Bir SOAP hatası, protokolün hata yapısıdır. Bir faultcode, bir faultstring ve bazen bir detail öğesi taşır. Bir HTTP 200 ile geldiği için, yalnızca durumu kontrol eden bir test, başarısız bir çağrıyı başarılı olarak kabul edecektir. Bu, sessiz, tehlikeli bir yanlış pozitiftir.

SOAP doğrulamalarınızı gövde içine bakacak şekilde yazın. Başarılı bir akışta <soap:Fault> öğesinin bulunmadığını doğrulayın. Kasıtlı bir hata akışında ise tam tersini, yani hatanın göründüğünü ve faultcode'un beklediğinizle eşleştiğini doğrulayın. Başarısızlık durumlarını test etmek, başarılı akışı test etmek kadar önemlidir, çünkü SOAP hizmetleri genellikle reddedilen bir işlem gibi iş kurallarını veri yerine hata olarak kodlar. Resmi ayrıntılara ihtiyacınız olursa, W3C SOAP hata dokümantasyonu yapıyı açıklar.

WS-Security başka bir katman ekler. Birçok kurumsal SOAP hizmeti, imzalı veya token taşıyan bir güvenlik başlığı bekler. İstekleriniz bir kimlik doğrulama hatasıyla başarısız olursa, WSDL veya hizmet belgeleri hangi güvenlik profilinin devrede olduğunu söyleyecektir. SoapUI ve Apidog gibi araçlar, bu başlıkları elle XML oluşturmak yerine yapılandırmanıza olanak tanır.

WSDL'yi kaybolmadan okumak

Bir WSDL dosyası, ilk açtığınızda göz korkutucu görünebilir. Uzun, derinlemesine iç içe geçmiş bir XML'dir ve çoğu makine altyapısıdır. Hepsini okumanıza gerek yoktur. Dört bölüm, gerçekten istediğiniz bilgileri taşır.

types bölümü veri yapılarını, genellikle XML Şeması olarak tanımlar, bu nedenle her parametrenin tam şeklini ve kısıtlamalarını buradan öğrenirsiniz. message öğeleri her işlem için girdi ve çıktıyı açıklar. portType, yapabileceğiniz çağrılar olan işlemlerin kendilerini listeler. service ve binding bölümleri, somut uç nokta adresini ve taşıma ayrıntılarını verir. Bir WSDL'yi bir araca aktardığınızda, dördünü de okur ve düzenlemeye hazır isteklere dönüştürür, bu yüzden aktarım her zaman elle yazmaktan daha iyidir.

Bilmeye değer bir ayrıntı: Bir WSDL, import ifadeleri kullanarak birden çok dosyaya bölünebilir ve genellikle şemaları ayrı konumlardan çeker. Aracınız eksik bir tür bildirirse, referans verilen bir dosya muhtemelen çözümlenememiştir. Aracınızın çalıştığı yerden her içe aktarılan URL'nin erişilebilir olduğundan emin olun. Bu tür bir sözleşme bağımlılığı, ekiplerin WSDL'yi yalnızca bir sunucuda yaşayan bir şey yerine sürüm kontrollü bir yapıt olarak ele almasının nedenidir.

Veri odaklı SOAP testi

SOAP hizmetleri genellikle katı iş kuralları taşır ve tek bir başarılı akış isteği nadiren çok şey kanıtlar. Bir para birimi hizmeti, geçerli çiftlerle, desteklenmeyen bir para birimiyle, sıfır miktarla ve negatif bir miktarla test edilmelidir. Bir ödeme hizmeti, onaylanmış bir kartla, reddedilmiş bir kartla ve süresi dolmuş bir kartla test edilmelidir. Bunların her birini elle yazmak yavaştır ve hata yapmaya müsaittir.

Veri odaklı test bunu çözer. İsteği bir kez yer tutucularla yazarsınız, ardından ona bir girdi satırları ve beklenen sonuçlar tablosu beslersiniz. Araç, her satır için isteği çalıştırır ve her sonucu kontrol eder. SoapUI bu deseni yıllardır desteklemektedir ve Apidog bunu senaryo çalıştırıcısı aracılığıyla destekler. Bunun getirisi, SOAP hizmetlerinin hata olarak kodlama eğiliminde olduğu uç durumların gerçek kapsamıdır. Daha geniş desen için, CSV ve JSON ile veri odaklı API testi kılavuzumuz girdi verilerinin nasıl yapılandırılacağını açıklar ve bu, SOAP'a tıpkı REST'e uygulandığı gibi uygulanır.

Sıkça sorulan sorular

SOAP ve REST testi arasındaki fark nedir?

SOAP testi, WSDL sözleşmeli, zorunlu zarflara sahip ve HTTP 200 gövdesi içinde döndürülen hatalarla birlikte katı bir XML protokolüne karşı çalışır. REST testi genellikle JSON, daha esnek kurallar ve anlamlı HTTP durum kodlarıyla ilgilenir. Bir SOAP testinin başarıyı doğrulamak için yanıt gövdesini ayrıştırması gerekir; bir REST testi genellikle durum koduna güvenebilir.

Bir SOAP API'sini test etmek için WSDL'ye ihtiyacım var mı?

Kesin zarf yapısını zaten biliyorsanız WSDL olmadan da bir SOAP isteği gönderebilirsiniz. Ancak WSDL, araçlar doğru istek şablonlarını ondan oluşturduğu için testi çok daha kolay hale getirir. Çoğu hizmet, uç nokta URL'sine ?wsdl ekleyerek WSDL'yi sunar. Her zaman oradan başlayın.

SOAP isteğim neden durumu 200 olmasına rağmen bir hata (fault) döndürüyor?

SOAP, hataları bir HTTP hata kodu olarak değil, gövde içindeki bir <soap:Fault> öğesi olarak bildirir, bu nedenle bir hatayla birlikte 200 normaldir. Yaygın nedenler eksik veya yanlış SOAPAction başlığı, hatalı biçimlendirilmiş bir zarf, ad alanı uyumsuzluğu veya başarısız bir güvenlik kontrolüdür. Belirli nedeni öğrenmek için faultstring'i okuyun.

SOAP API'lerini çevrimiçi olarak ücretsiz test edebilir miyim?

Evet. Apidog, ücretsiz katmanında SOAP'ı destekler ve WSDL dosyalarını içe aktarır, ayrıca SoapUI'nin açık kaynak sürümü de SOAP için yapılmıştır. Hızlı kontroller için hafif tarayıcı test araçları da mevcuttur, ancak bunlar gerçek doğrulama ve otomasyon desteğinden yoksundur.

SOAP API testlerini nasıl otomatikleştiririm?

WSDL'yi içe aktarın, işlemleri sırayla zincirleyen bir senaryo oluşturun, yanıt öğeleri ve hata yokluğu üzerinde doğrulamalar ekleyin, ardından bunu bir aracın çalıştırıcısından veya CI (Sürekli Entegrasyon) hattınızdan çalıştırın. SoapUI ve Apidog'un her ikisi de planlanmış ve pipeline tetiklemeli SOAP paketlerini destekler, bu nedenle bir SOAP regresyon çalıştırması REST ile aynı otomasyon akışına uyar.