Sie haben einen SOAP-Endpunkt erhalten. Vielleicht ist es ein alter Währungsrechner, von dem Ihr Abrechnungsteam noch abhängt, oder ein Auftragsverwaltungs-Webdienst, den ein Partner mit .NET betreibt. Sie müssen ihn aufrufen, bestätigen, dass er das vertraglich Versprochene zurückgibt, und beweisen, dass er korrekt bleibt, während sich der umgebende Code ändert. REST-Tools passen nicht ganz, da SOAP einen vollständigen XML-Envelope, einen spezifischen Content-Type und eine WSDL benötigt, die jede Operation beschreibt.
Apidog verarbeitet SOAP- und WebService-Anfragen neben REST, GraphQL und gRPC, sodass Sie keine separate App für den einen Altdienst in Ihrem Stack benötigen. Dieser Leitfaden führt Sie durch beide dokumentierten Wege: das manuelle Senden einer SOAP-Anfrage und das Importieren einer WSDL, damit Apidog die Umgebung und Endpunkte für Sie erstellt. Wenn Sie zuerst einen breiteren Überblick über die Protokolle wünschen, zeigt unser Vergleich von REST, GraphQL, gRPC und SOAP, wo jedes seinen Platz findet. Für die formale Definition der Envelope-Struktur ist die W3C SOAP-Spezifikation die maßgebliche Quelle.
Was SOAP ist und warum es eine andere Handhabung erfordert
Apidog beschreibt SOAP als Simple Object Access Protocol, ein XML-basiertes Kommunikationsprotokoll, das es verschiedenen Plattformen und Programmiersprachen ermöglicht, miteinander zu kommunizieren. Diese eine Idee erklärt, warum so viele Unternehmen es immer noch nutzen. Ein Java-Client und ein .NET-Dienst können über denselben Vertrag kommunizieren, ohne sich um die internen Details des jeweils anderen kümmern zu müssen.
Drei Eigenschaften sind beim Testen wichtig. SOAP verwendet XML zur Nachrichtenformatierung, daher ist jede Anfrage und Antwort ein strukturiertes Dokument, kein loses JSON-Blob. Wenn XML selbst Neuland für Sie ist, ist die XML-Referenz von MDN eine solide Einführung in die Syntax, die Sie lesen und schreiben werden. Es wird normalerweise über HTTP oder HTTPS übertragen, obwohl das Protokoll auch andere unterstützt. Und es folgt den W3C-Standards für strukturierte, zuverlässige Kommunikation, weshalb die Nachrichtenform streng und die Validierungsregeln fest sind.
Diese Strenge ist der Grund, warum SOAP-Endpunkte für plattformübergreifende Integration, Brücken von Legacy- zu modernen Systemen und sichere Transaktionen mit WS-Security für verschlüsselte, authentifizierte Nachrichten im Einsatz bleiben. Es ist auch der Grund, warum Sie nicht einfach eine REST-ähnliche Anfrage an einen solchen senden können. Sie benötigen den richtigen Header, einen XML-Body, der in einen SOAP-Envelope gehüllt ist, und eine Möglichkeit, das zurückkommende XML zu lesen. Wenn Sie einen tieferen Einblick in die Funktionsweise des Envelopes und seines Body wünschen, lesen Sie unsere Aufschlüsselung von SOAP-APIs und XML.
Bevor Sie beginnen
Eine wichtige Voraussetzung gilt für alles Folgende. Um eine SOAP- oder WebService-Anfrage zu senden, muss Apidog Version 2.1.31 oder höher sein. Ältere Builds unterstützen dies nicht. Öffnen Sie Apidog, überprüfen Sie Ihre Version und aktualisieren Sie, falls Sie hinterherhinken. Alles andere in diesem Leitfaden geht davon aus, dass Sie Version 2.1.31 oder höher verwenden.
Wenn Sie Apidog noch nicht haben, laden Sie Apidog herunter und machen Sie mit. Probieren Sie es kostenlos aus, keine Kreditkarte erforderlich.
Sie benötigen außerdem die Details Ihres Zieldienstes: die Endpunkt-URL, den Namen der Operation, die Sie aufrufen möchten, und deren Parameter. Wenn Sie eine WSDL-Datei haben, halten Sie diese bereit, da die zweite Hälfte dieses Leitfadens sie direkt importiert.
Pfad A: Eine SOAP-Anfrage manuell senden
Dies ist der Pfad, wenn Sie einen Endpunkt haben und die Operation kennen, die Sie aufrufen möchten. Es gibt drei Dinge, die Sie einstellen müssen, die eine REST-Anfrage nicht benötigt, und das richtige Einstellen ist die ganze Arbeit.
Schritt 1: Den Content-Type-Header manuell setzen
SOAP-Anfragen leiten ihren eigenen Header nicht ab. Sie legen den Content-Type selbst fest, und es gibt zwei gültige Werte:
text/xml; charset=utf-8application/soap+xml
Welcher der richtige ist, hängt vom Dienst ab. SOAP 1.1-Endpunkte erwarten typischerweise text/xml; charset=utf-8, während SOAP 1.2-Endpunkte oft application/soap+xml wünschen. Wenn Sie unsicher sind, überprüfen Sie die WSDL oder die Dienst-Dokumentation, und wenn der erste Wert einen Fehler bezüglich des Inhaltstyps zurückgibt, wechseln Sie zum anderen. Fügen Sie den Header im Abschnitt "Headers" der Anfrage hinzu, bevor Sie senden.
Schritt 2: Das Body-Format auf XML setzen und den Envelope einfügen
Setzen Sie das Anforderungs-Body-Format auf xml und fügen Sie dann den SOAP-Envelope ein. Der Envelope ist ein Dokument mit Namespace-Deklarationen und einem Body-Element, das die aufgerufene Operation sowie alle darin verschachtelten Parameter enthält.
Hier ist ein funktionierendes Beispiel für einen öffentlichen Zahlen-zu-Wörtern-Dienst, die gleiche Form, die Apidog in seiner Dokumentation verwendet. Die Operation ist NumberToWords und nimmt einen Parameter, 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>
Der Namespace für die Operation muss dem entsprechen, was der Dienst erwartet, weshalb Sie ihn aus der WSDL lesen, anstatt zu raten. Der soap:Body umschließt den eigentlichen Aufruf; web:NumberToWords ist die Operation; web:ubiNum ist die Eingabe.
Schritt 3: Senden und die XML-Antwort lesen
Senden Sie die Anfrage. Die Antwort kommt im XML-Format zurück, als SOAP-Envelope, dessen Body die Antwortoperation enthält. Für den obigen Aufruf erhalten Sie eine NumberToWordsResponse mit dem Ergebnis darin verschachtelt:
<?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>
Die Antwort spiegelt die Anfrage wider: Der Operationsname erhält ein Response-Suffix, und der Wert landet in einem Ergebniselement. Diese Spiegelung ist das, worauf Sie sich verlassen. Sie bestätigen, dass der Envelope zurückkam, der Knoten NumberToWordsResponse existiert und das Ergebnis Ihren Erwartungen entspricht. Die dedizierte WebService-Dokumentation von Apidog unter webservice.apidog.io enthält die vollständige Konfigurationsreferenz und weitere Beispiel-Envelopes, falls Sie ein zweites funktionierendes Beispiel wünschen.
Ein realistischer Anwendungsfall folgt den gleichen drei Schritten. Ersetzen Sie NumberToWords durch eine ConvertCurrency-Operation auf einem älteren Wechselkursdienst, übergeben Sie fromCurrency, toCurrency und amount als verschachtelte Elemente und lesen Sie den konvertierten Wert aus dem Antwort-Envelope. Oder rufen Sie eine GetOrderStatus-Operation auf einem Auftrags-Webdienst auf, übergeben Sie eine orderId und prüfen Sie den zurückgegebenen Statusknoten. Die Mechanik ändert sich nie: Header, XML-Body, senden, den Envelope lesen.
Pfad B: Eine WSDL importieren, um die Endpunkte zu generieren
Das manuelle Eintippen von Envelopes ist für einen einzelnen Aufruf in Ordnung. Wenn ein Dienst ein Dutzend Operationen exponiert, lassen Sie die WSDL die Arbeit erledigen. Eine WSDL-Datei beschreibt jede Operation, ihre Eingaben und die Dienstadresse, und Apidog liest all dies in einem einzigen Import ein.
Hier ist der genaue Klickpfad:
- Gehen Sie zu "Einstellungen" (Settings) und dann zu "Daten importieren" (Import Data).
- Wählen Sie
WSDL. - Laden Sie Ihre
.wsdl- oder.xml-Datei hoch. - Überprüfen Sie die Vorschau der API-Endpunkte, die Apidog aus der Datei geparst hat.
- Öffnen Sie den Tab
Umgebungen(Environments) und vergewissern Sie sich, dass die Dienstadresse korrekt ist. - Klicken Sie auf
Bestätigen(Confirm). Die importierte Umgebung wird automatisch erstellt. - Wählen Sie die importierte Umgebung oben rechts aus.
- Senden Sie eine Anfrage. Die Basis-URL wird automatisch aus dieser Umgebung übernommen.
Zwei Schritte in dieser Liste werden oft übersprungen und dann bereut.
Schritt 5 ist wichtig, weil die Dienstadresse in der WSDL der Endpunkt ist, den jede importierte Anfrage treffen wird. Wenn sie auf einen Staging-Host oder eine Platzhalter-URL verweist, die der WSDL-Autor nie aktualisiert hat, gehen Ihre Anfragen an den falschen Ort. Überprüfen Sie dies im Tab Umgebungen, *bevor* Sie auf Bestätigen klicken, nicht danach.
Schritt 7 ist wichtig, weil die Basis-URL in dieser automatisch erstellten Umgebung gespeichert ist. Wenn Sie die importierte Umgebung nicht oben rechts auswählen, haben Ihre Anfragen keine Basisadresse und schlagen fehl. Wählen Sie sie zuerst aus, dann senden Sie.
Nach dem Import wird jede Operation als Endpunkt angezeigt, den Sie aufrufen können, ohne den Envelope selbst schreiben zu müssen, und Sie prüfen die XML-Antwort genau wie in Pfad A. Wenn Sie ein ganzes Projekt von einem anderen Tool migrieren, behandelt unser Leitfaden zum Importieren von SOAP-Projekten die Migration von Anfang bis Ende.
Beachten Sie eine ehrliche Einschränkung: Der WSDL-Import ist für den Dateiupload von .wsdl- und .xml-Dateien dokumentiert. Das Importieren einer WSDL über URL oder durch Einfügen ihres Inhalts ist nicht dokumentiert, laden Sie also die Datei hoch, anstatt ein URL-Feld zu erwarten.
Von SoapUI kommend
Wenn Ihre SOAP-Tests derzeit in SoapUI existieren, müssen Sie sie nicht von Grund auf neu erstellen. Exportieren oder behalten Sie Ihre WSDL, importieren Sie sie mit Pfad B in Apidog, und Sie erhalten dieselben Operationen als aufrufbare Endpunkte in einem Workspace, der auch Design, Mocking und Dokumentation bietet. Der Vorteil ist die Konsolidierung: Ein Projekt enthält Ihren SOAP-Dienst, Ihre REST-Endpunkte und Ihre Testszenarien, anstatt sie über separate Tools zu verteilen. Unser direkter Vergleich von Apidog versus SoapUI erklärt, was übernommen wird und wo sich die Workflows unterscheiden.
Assertions und Variationen
Ein einziger erfolgreicher Aufruf beweist, dass der Endpunkt aktiv ist. Ein Test beweist, dass er korrekt ist. Sobald Ihre SOAP-Anfrage zurückkehrt, fügen Sie Assertions für den Antwort-Envelope hinzu: Bestätigen Sie, dass der erwartete Antwort-Operationsknoten vorhanden ist, extrahieren Sie das Ergebniselement und überprüfen Sie seinen Wert anhand dessen, was der Vertrag verspricht. Bei einem Währungsdienst bestätigen Sie, dass der konvertierte Betrag eine Zahl im Bereich ist; bei einem Bestelldienst bestätigen Sie, dass der Status einer der zulässigen Werte ist.
Von dort aus erstellen Sie ein wiederholbares Testszenario, das Aufrufe miteinander verknüpft, z. B. eine Bestellung erstellt und dann ihren Status abfragt, wobei Werte zwischen den Schritten übergeben werden. Unsere Anleitung zum Schreiben eines Testszenarios mit Apidog zeigt, wie extrahierte Werte in spätere Anfragen integriert werden. Das Muster ist protokollunabhängig, sodass ein Szenario einen SOAP-Aufruf mit den umgebenden REST-Endpunkten mischen kann.
Für gesicherte Endpunkte verwendet SOAP häufig WS-Security für verschlüsselte, authentifizierte Nachrichten. Dieser Security-Header ist Teil des von Ihnen gesendeten SOAP-Envelopes, daher fügen Sie den wsse-Security-Block im Header des Envelopes neben Ihrer Operation hinzu. Die Mechanismen des Sendens bleiben gleich: Setzen Sie den Content-Type, legen Sie den vollständigen Envelope einschließlich des Security-Headers in den XML-Body und senden Sie.
Automatisieren Sie den Workflow mit der Apidog CLI
Sobald Ihre SOAP- oder WSDL-importierten Anfragen als Testszenarien gespeichert sind, führt die Apidog CLI diese von der Befehlszeile aus aus, sodass eine Pipeline sie bei jedem Push überprüfen kann. Installieren Sie sie mit Node.js v16 oder höher und authentifizieren Sie sich dann:
npm install -g apidog-cli
apidog login --with-token <YOUR_ACCESS_TOKEN>
Führen Sie ein gespeichertes Szenario anhand der ID aus, gegen die Umgebung, die Ihr WSDL-Import erstellt hat:
apidog run --access-token $APIDOG_ACCESS_TOKEN -t <scenario_id> -e <env_id> -r cli
Hier ist -t die Test-Szenario-ID, -e die Umgebungs-ID und -r der Reporter (cli, html oder junit, durch Komma getrennt für mehrere). Eine ehrliche Einschränkung: Die Dokumentation bestätigt, dass der Runner gespeicherte Testszenarien und Suiten ausführt, aber es wird nicht angegeben, ob Szenarien, die auf SOAP-Schritten basieren, headless ausgeführt werden. Betrachten Sie die CLI daher als Ihre Engine für die HTTP-Szenarien des Projekts und um die WSDL-importierten Endpunkte in der CI synchron zu halten, anstatt eine SOAP-spezifische Ausführung anzunehmen. Die Integration in eine Pipeline wird in unserem Apidog CLI CI/CD-Leitfaden behandelt.
FAQ
Welchen Content-Type sollte ich für eine SOAP-Anfrage verwenden? Entweder text/xml; charset=utf-8 oder application/soap+xml. Der richtige hängt vom Dienst ab: SOAP 1.1-Endpunkte erwarten im Allgemeinen den ersten, SOAP 1.2-Endpunkte den zweiten. Stellen Sie ihn manuell in den Anforderungs-Headern ein, und wenn Sie einen Content-Type-Fehler erhalten, wechseln Sie zum anderen Wert.
Benötige ich einen kostenpflichtigen Plan, um SOAP in Apidog zu testen? Die einzige dokumentierte Anforderung ist, dass Apidog Version 2.1.31 oder höher ist. Es gibt keine Einschränkung der Tarifstufen oder selbstgehosteten Einschränkungen für SOAP- oder WSDL-Unterstützung, also aktualisieren Sie auf eine aktuelle Version und Sie sind startklar.
Kann ich eine WSDL von einer URL importieren? Der dokumentierte WSDL-Import akzeptiert Dateiuploads von .wsdl- und .xml-Dateien. Das Importieren über URL oder durch Einfügen des WSDL-Textes ist nicht dokumentiert, laden Sie also die Datei hoch. Nach dem Import wird die Umgebung automatisch erstellt, und Sie wählen sie vor dem Senden oben rechts aus.
Wie teste ich SOAP- und REST-APIs im selben Projekt? Apidog behandelt sie als Anfragetypen innerhalb eines Workspaces, sodass ein einziges Projekt SOAP-Operationen neben REST-Endpunkten und sogar GraphQL-Aufrufen enthalten kann. Wenn GraphQL ebenfalls auf Ihrer Agenda steht, deckt unser Leitfaden zum Testen von GraphQL-APIs in Apidog diese Seite ab, und ein Testszenario kann Anfragen über alle hinweg verketten.
Meine WSDL-importierten Anfragen treffen den falschen Server. Was ist passiert? Zwei übliche Ursachen. Entweder war die Dienstadresse im Tab Umgebungen zum Zeitpunkt des Imports falsch und Sie haben auf Bestätigen geklickt, ohne sie zu überprüfen, oder Sie haben die importierte Umgebung nicht oben rechts ausgewählt, sodass keine Basis-URL angewendet wurde. Importieren Sie erneut und überprüfen Sie die Adresse, stellen Sie dann sicher, dass die richtige Umgebung aktiv ist, bevor Sie senden.
Zusammenfassung
Das Testen von SOAP muss kein separates Legacy-Tool bedeuten. In Apidog senden Sie entweder den Envelope manuell (Content-Type setzen, den Body auf xml setzen, den Envelope einfügen, die XML-Antwort lesen) oder importieren eine WSDL und lassen Apidog die Endpunkte und die Umgebung für Sie erstellen. Beide Wege führen zum selben Ziel: eine wiederholbare Überprüfung, dass Ihr Webdienst seinen Vertrag immer noch einhält. Laden Sie Apidog in Version 2.1.31 oder höher herunter, importieren Sie Ihre WSDL und unterziehen Sie Ihre Legacy-Dienste denselben Tests wie den Rest Ihrer API-Oberfläche.