Ga naar inhoud

SOAP

Rechtsklik in de boom ▸ Toevoegen ▸ SOAP-verzoek.

Een SOAP-tabblad: de URL van de service, de regel service / operatie / SOAPAction, en de XML-envelop in de editor

VeldRol
URLHet eindpunt van de service
SOAPActionDe SOAPAction-header van de operatie
Service / OperatieDe namen uit het WSDL, gebruikt voor de routering en de weergave
BodyDe ruwe SOAP-envelop, in XML
HeadersDe HTTP-headers van het transport

De envelop bewerkt u zoals hij is, met syntaxiskleuring en opmaak. De {{variabelen}} werken daar normaal.

Dat is de aanbevolen route: met Bestand ▸ Importeren van een .wsdl (of een WSDL-URL) bouwt Restorm één map per service en port en één verzoek per operatie, met SOAPAction ingevuld en een envelop die op basis van het schema is voorgevuld — plus de API-documentatie en de enumeraties. Zie Een WSDL importeren.

Een <soap:Fault>-respons wordt als zodanig weergegeven: Restorm laat het niet bij een ondoorzichtige HTTP-status 500, maar licht de inhoud van de fault uit in het responspaneel.

Restorm kan een SOAP-mockservice hosten. Elke gemockte operatie wordt in de eerste plaats gematcht op SOAPAction en anders op de naam van het eerste kind van <soap:Body>. Een operatie kan als fault worden gemarkeerd, waardoor er een <soap:Fault> met HTTP-status 500 wordt teruggegeven. Zie Een SOAP-service mocken.

Vijftien doelen, waaronder de varianten “SOAP-client” en “ruwe HTTP” van elk ecosysteem: cURL, JavaScript (Fetch, soap npm), TypeScript, Python (zeep, ruwe Requests), C# (WCF, ruwe HttpClient), Java (JAX-WS, ruwe HttpURLConnection), PHP (SoapClient, ruwe cURL), Ruby (savon), Go (net/http), PowerShell.