Elinize bir SOAP uç noktası ulaştı. Belki de faturalama ekibinizin hala bağlı olduğu eski bir para birimi dönüştürücüsü veya bir iş ortağının .NET üzerinde çalıştırdığı bir sipariş yönetimi web hizmetidir. Onu çağırmanız, sözleşmenin vaat ettiklerini döndürdüğünü doğrulamanız ve etrafındaki kod değiştikçe doğru kaldığını kanıtlamanız gerekiyor. REST araçları tam olarak uymuyor, çünkü SOAP tam bir XML zarfı, belirli bir Content-Type ve her işlemi açıklayan bir WSDL ister.
Apidog, REST, GraphQL ve gRPC ile birlikte SOAP ve Web Hizmeti isteklerini de yönetir, böylece yığınınızdaki tek eski hizmet için ayrı bir uygulamaya ihtiyacınız olmaz. Bu kılavuz, belgelenmiş iki yolu da adım adım açıklar: bir SOAP isteğini elle göndermek ve Apidog'un sizin için ortamı ve uç noktaları oluşturması için bir WSDL'yi içe aktarmak. Önce daha geniş bir protokol resmini görmek isterseniz, REST, GraphQL, gRPC ve SOAP karşılaştırmamız her birinin yerini nerede kazandığını ortaya koyar. Zarf yapısının resmi tanımı için W3C SOAP spesifikasyonu yetkili kaynaktır.
SOAP nedir ve neden farklı bir işleme ihtiyacı vardır
Apidog, SOAP'ı, farklı platformların ve programlama dillerinin birbiriyle konuşmasını sağlayan XML tabanlı bir iletişim protokolü olan Basit Nesne Erişim Protokolü olarak tanımlar. Bu fikir, neden bu kadar çok şirketin hala onu kullandığını açıklıyor. Bir Java istemcisi ve bir .NET hizmeti, birbirlerinin iç işleyişlerini önemsemeden aynı sözleşme üzerinden konuşabilir.
Test ederken üç özellik önemlidir. SOAP, mesaj biçimlendirmesi için XML kullanır, bu nedenle her istek ve yanıt, gevşek bir JSON blobu değil, yapılandırılmış bir belgedir. XML'in kendisi size yabancı geliyorsa, MDN'nin XML referansı, okuyacağınız ve yazacağınız sözdizimi hakkında sağlam bir başlangıçtır. Genellikle HTTP veya HTTPS üzerinden iletilir, ancak protokol başkalarını da destekler. Ve yapılandırılmış, güvenilir iletişim için W3C standartlarını takip eder, bu yüzden mesaj şekli katı ve doğrulama kuralları kesindir.
Bu katılık, SOAP uç noktalarının platformlar arası entegrasyon, eski sistemlerden modern sistemlere köprüler ve şifreli, doğrulanmış mesajlaşma için WS-Security kullanan güvenli işlemler için hizmette kalmasının nedenidir. Ayrıca bir REST tarzı isteği doğrudan gönderememenizin nedeni de budur. Doğru başlığa, bir SOAP zarfına sarılmış bir XML gövdesine ve geri dönen XML'i okumanın bir yoluna ihtiyacınız vardır. Zarfın ve gövdesinin verileri nasıl taşıdığına daha derinlemesine bakmak isterseniz, SOAP API'leri ve XML hakkındaki analizimize göz atın.
Başlamadan önce
Aşağıdakilerin hepsi için katı bir gereksinim vardır. Bir SOAP veya Web Hizmeti isteği göndermek için Apidog'un 2.1.31 veya daha yüksek bir sürümde olması gerekir. Daha eski yapılar bunu desteklemez. Apidog'u açın, sürümünüzü kontrol edin ve gerideyseniz güncelleyin. Bu kılavuzdaki diğer her şey, 2.1.31 veya sonraki bir sürümde olduğunuzu varsayar.
Henüz Apidog'unuz yoksa, Apidog'u indirin ve takip edin. Ücretsiz deneyin, kredi kartı gerekmez.
Ayrıca hedef hizmetinizin ayrıntılarını elinizde bulundurmanız gerekir: uç nokta URL'si, çağırmak istediğiniz işlem adı ve parametreleri. Bir WSDL dosyanız varsa, elinizin altında bulundurun, çünkü bu kılavuzun ikinci yarısı onu doğrudan içe aktarır.
Yol A: Bir SOAP isteğini elle gönderme
Bu, bir uç noktanız olduğunda ve çağırmak istediğiniz işlemi bildiğinizdeki yoldur. Bir REST isteğinin ihtiyaç duymadığı üç şeyi ayarlarsınız ve bunları doğru yapmak tüm iştir.
Adım 1: Content-Type başlığını manuel olarak ayarlayın
SOAP istekleri kendi başlıklarını çıkarmaz. Content-Type'ı kendiniz ayarlarsınız ve iki geçerli değeri vardır:
text/xml; charset=utf-8application/soap+xml
Hangisinin doğru olduğu hizmete bağlıdır. SOAP 1.1 uç noktaları tipik olarak text/xml; charset=utf-8 beklerken, SOAP 1.2 uç noktaları genellikle application/soap+xml ister. Emin değilseniz, WSDL'yi veya hizmet dokümantasyonunu kontrol edin ve ilk değer içerik türüyle ilgili bir hata döndürürse diğerine geçin. Göndermeden önce başlığı isteğin Başlıklar bölümüne ekleyin.
Adım 2: Gövde formatını XML olarak ayarlayın ve zarfı yapıştırın
İsteğin Gövde formatını xml olarak ayarlayın, ardından SOAP zarfını yapıştırın. Zarf, ad alanı bildirimleri ve çağırdığınız işlemi ve içine yerleştirilmiş tüm parametreleri içeren bir Gövde öğesi olan bir belgedir.
Apidog'un dokümantasyonunda kullandığı aynı şekilde, herkese açık bir sayıdan kelimeye dönüştürme hizmetine karşı çalışan bir örnek: İşlem NumberToWords'tür ve tek bir parametre alır: ubiNum:
<?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>
İşlemdeki ad alanı, hizmetin beklediğiyle eşleşmelidir, bu yüzden onu tahmin etmek yerine WSDL'den okursunuz. soap:Body gerçek çağrıyı sarar; web:NumberToWords işlemdir; web:ubiNum girdidir.
Adım 3: XML yanıtını gönderin ve okuyun
İsteği gönderin. Yanıt, Gövdesi yanıt işlemini içeren bir SOAP zarfı olarak XML formatında geri döner. Yukarıdaki çağrı için, sonuç içine yerleştirilmiş bir NumberToWordsResponse alırsınız:
<?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 isteği yansıtır: işlem adı bir Response son eki alır ve değer bir sonuç öğesine yerleşir. Karşılaştırma yaptığınız şey bu yansımadır. Zarfın geri döndüğünü, NumberToWordsResponse düğümünün mevcut olduğunu ve sonucun beklediğinizle eşleştiğini doğrularsınız. Apidog'un webservice.apidog.io adresindeki özel Web Hizmeti dokümantasyonu, ikinci bir çalışan örnek isterseniz tüm yapılandırma referansını ve daha fazla örnek zarfı içerir.
Gerçekçi bir kullanım durumu aynı üç adımı takip eder. NumberToWords'ü eski bir döviz kuru hizmetindeki ConvertCurrency işlemiyle değiştirin, fromCurrency, toCurrency ve amount'ı iç içe öğeler olarak geçirin ve dönüştürülen rakamı yanıt zarfından okuyun. Ya da bir sipariş web hizmetinde GetOrderStatus işlemini çağırın, bir orderId geçirin ve dönen durum düğümü üzerinde doğrulama yapın. Mekanizma asla değişmez: başlık, xml gövdesi, gönder, zarfı oku.
Yol B: Uç noktaları oluşturmak için bir WSDL içe aktarma
Zarfları elle yazmak tek bir çağrı için iyidir. Bir hizmet bir düzine işlem ifşa ettiğinde, bırakın WSDL işi yapsın. Bir WSDL dosyası her işlemi, girdilerini ve hizmet adresini açıklar ve Apidog tüm bunları tek bir içe aktarmada okur.
İşte tam tıklama yolu:
- Ayarlar'a gidin, ardından Veri İçe Aktar'ı seçin.
WSDL'yi seçin..wsdlveya.xmldosyanızı yükleyin.- Apidog'un dosyadan ayrıştırdığı API uç noktalarının önizlemesini inceleyin.
Ortamlarsekmesini açın ve hizmet adresinin doğru olduğunu doğrulayın.Onayla'ya tıklayın. İçe aktarılan ortam otomatik olarak oluşturulur.- Sağ üst köşeden içe aktarılan ortamı seçin.
- Bir istek gönderin. Temel URL o ortamdan otomatik olarak uygulanır.
Bu listedeki iki adım, insanların atlayıp sonra pişman oldukları adımlardır.
Adım 5 önemlidir çünkü WSDL'deki hizmet adresi, içe aktarılan her isteğin ulaşacağı uç noktadır. Eğer bir hazırlık ortamına veya WSDL yazarının hiç güncellemediği bir yer tutucu URL'ye işaret ediyorsa, istekleriniz yanlış yere gider. Onayla'ya tıklamadan önce, sonra değil, Ortamlar sekmesinde kontrol edin.
Adım 7 önemlidir çünkü Temel URL otomatik olarak oluşturulan bu ortamda bulunur. Sağ üst köşeden içe aktarılan ortamı seçmezseniz, isteklerinizin temel adresi olmaz ve başarısız olurlar. Önce onu seçin, sonra gönderin.
İçe aktardıktan sonra, her işlem zarfı kendiniz yazmadan çağırabileceğiniz bir uç nokta olarak görünür ve XML yanıtı üzerinde Yol A'daki gibi doğrulama yaparsınız. Tüm bir projeyi başka bir araçtan taşıyorsanız, SOAP projelerini içe aktarma kılavuzumuz geçişi baştan sona kapsar.
Dürüst bir sınırlamaya dikkat edin: WSDL içe aktarma, .wsdl ve .xml dosyalarının dosya yüklemesi için belgelenmiştir. Bir WSDL'yi URL ile veya içeriğini yapıştırarak içe aktarma belgelenmemiştir, bu yüzden bir URL alanı beklemek yerine dosyayı yükleyin.
SoapUI'dan Geçiş
SOAP testleriniz şu anda SoapUI'da bulunuyorsa, onları sıfırdan yeniden oluşturmanıza gerek yok. WSDL'nizi dışa aktarın veya saklayın, Yol B ile Apidog'a aktarın ve tasarım, sahte yanıtlama ve dokümantasyon da yapan bir çalışma alanı içinde çağrılabilir uç noktalar olarak aynı işlemleri elde edersiniz. Kazanç konsolidasyondur: tek bir proje, SOAP hizmetinizi, REST uç noktalarınızı ve test senaryolarınızı ayrı araçlara dağıtmak yerine bir arada tutar. Apidog ve SoapUI karşılaştırmamız, nelerin aktarılabileceğini ve iş akışlarının nerede farklılaştığını ayrıntılarıyla anlatır.
Doğrulamalar ve varyasyonlar
Tek bir başarılı çağrı, uç noktanın çalıştığını kanıtlar. Bir test ise doğru olduğunu kanıtlar. SOAP isteğiniz geri döndüğünde, yanıt zarfı üzerinde doğrulamalar ekleyin: beklenen yanıt işlem düğümünün mevcut olduğunu onaylayın, sonuç öğesini çıkarın ve değerini sözleşmenin vaat ettikleriyle karşılaştırın. Bir para birimi hizmeti için dönüştürülen miktarın belirli bir aralıkta bir sayı olduğunu doğrularken; bir sipariş hizmeti için durumun izin verilen değerlerden biri olduğunu doğrulayın.
Buradan, çağrıları zincirleyen tekrarlanabilir bir test senaryosu oluşturursunuz; örneğin bir sipariş oluşturun, ardından durumunu sorgulayın, adımlar arasında değerler geçirin. Apidog ile test senaryosu yazma hakkındaki rehberimiz, çıkarılan değerleri sonraki isteklere nasıl bağlayacağınızı gösterir. Bu desen protokolden bağımsızdır, bu nedenle bir senaryo bir SOAP çağrısını etrafındaki REST uç noktalarıyla karıştırabilir.
Güvenli uç noktalar için SOAP, şifreli, doğrulanmış mesajlaşma için yaygın olarak WS-Security kullanır. Bu güvenlik başlığı, gönderdiğiniz SOAP zarfının bir parçasıdır, bu nedenle wsse güvenlik bloğunu işleminizle birlikte zarfın başlığına eklersiniz. Gönderme mekaniği aynı kalır: Content-Type'ı ayarlayın, güvenlik başlığı da dahil olmak üzere tüm zarfı XML gövdesine koyun ve gönderin.
İş Akışını Apidog CLI ile Otomatikleştirin
SOAP veya WSDL ile içe aktarılan istekleriniz test senaryoları olarak kaydedildiğinde, Apidog CLI bunları komut satırından çalıştırır, böylece bir pipeline her push işleminde bunları uygulayabilir. Node.js v16 veya üzeri ile kurun, ardından kimlik doğrulayın:
npm install -g apidog-cli
apidog login --with-token <YOUR_ACCESS_TOKEN>
WSDL içe aktarımınızın oluşturduğu ortama karşı, kaydedilmiş bir senaryoyu kimliğine göre çalıştırın:
apidog run --access-token $APIDOG_ACCESS_TOKEN -t <scenario_id> -e <env_id> -r cli
Burada -t test senaryosu kimliği, -e ortam kimliği ve -r raporlayıcıdır (birkaçı için virgülle ayrılmış cli, html veya junit). Dürüst bir uyarı: belgeler çalıştırıcının kaydedilmiş test senaryolarını ve süitlerini çalıştırdığını doğruluyor, ancak SOAP adımları üzerine kurulu senaryoların başsız çalışıp çalışmadığını belirtmiyorlar, bu nedenle CLI'ı projenin HTTP senaryoları ve WSDL ile içe aktarılan uç noktaları CI'da senkronize tutmak için motorunuz olarak kabul edin, SOAP'a özel yürütmeyi varsaymayın. Bunu bir pipeline'a entegre etmek, Apidog CLI CI/CD kılavuzumuzda ele alınmıştır.
Sıkça Sorulan Sorular
Bir SOAP isteği için hangi Content-Type'ı kullanmalıyım? Ya text/xml; charset=utf-8 ya da application/soap+xml. Doğru olan hizmete bağlıdır: SOAP 1.1 uç noktaları genellikle birincisini, SOAP 1.2 uç noktaları ise ikincisini bekler. İstek başlıklarında manuel olarak ayarlayın ve içerik türü hatası alırsanız diğer değere geçin.
Apidog'da SOAP test etmek için ücretli bir plana ihtiyacım var mı? Belgelenen tek gereksinim, Apidog'un 2.1.31 veya daha yüksek bir sürümde olmasıdır. SOAP veya WSDL desteği için katman sınırlaması veya kendi kendine barındırma kısıtlaması belirtilmemiştir, bu nedenle güncel bir sürüme güncelleyin ve hazırsınız.
Bir WSDL'yi URL'den içe aktarabilir miyim? Belgelenen WSDL içe aktarma, .wsdl ve .xml dosyalarının dosya yüklemesini kabul eder. URL ile veya WSDL metnini yapıştırarak içe aktarma belgelenmemiştir, bu yüzden dosyayı yükleyin. İçe aktardıktan sonra ortam otomatik olarak oluşturulur ve göndermeden önce sağ üst köşeden onu seçersiniz.
Hem SOAP hem de REST API'lerini aynı projede nasıl test ederim? Apidog, bunları tek bir çalışma alanı içinde istek türleri olarak ele alır, bu nedenle tek bir proje SOAP işlemlerini REST uç noktalarının ve hatta GraphQL çağrılarının yanında tutabilir. Eğer GraphQL da gündeminizdeyse, Apidog'da GraphQL API'lerini test etme kılavuzumuz bu konuyu kapsar ve bir test senaryosu tüm bunları kapsayan istekleri zincirleyebilir.
WSDL ile içe aktarılan isteklerim yanlış sunucuya ulaşıyor. Ne oldu? İki yaygın neden. Ya `Ortamlar` sekmesindeki hizmet adresi içe aktarma sırasında yanlıştı ve kontrol etmeden `Onayla`'ya tıkladınız ya da sağ üst köşeden içe aktarılan ortamı seçmediniz, bu yüzden Temel URL uygulanmadı. Tekrar içe aktarın ve adresi doğrulayın, ardından göndermeden önce doğru ortamın aktif olduğundan emin olun.
Toparlayacak olursak
SOAP test etmek ayrı bir eski araç kullanmak anlamına gelmek zorunda değil. Apidog'da ya zarfı elle gönderirsiniz (`Content-Type`'ı ayarlayın, gövdeyi `xml` olarak ayarlayın, zarfı yapıştırın, XML yanıtını okuyun) ya da bir WSDL içe aktararak Apidog'un sizin için uç noktaları ve ortamı oluşturmasına izin verirsiniz. Her iki yol da aynı sonuca çıkar: web hizmetinizin hala sözleşmesine uygun davrandığına dair tekrarlanabilir bir kontrol. Apidog'u 2.1.31 veya daha yüksek sürümde indirin, WSDL'nizi içe aktarın ve eski hizmetlerinizi API yüzeyinizin geri kalanıyla aynı testlere tabi tutun.