SOAP

Most clients treat anything that is not JSON over HTTP as somebody else's problem. SOAP is a first-class body type here.

From a WSDL

Import → WSDL and give it a URL or a file. Every operation the service defines arrives as a request, in a collection, with:

• the envelope scaffolded for that operation
• SOAPAction set correctly
• the right Content-Type for the SOAP version

# The same thing, from the command line
sendwire add-soap https://example.com/service?wsdl

--dry-run shows what would be imported without writing anything, and --only picks specific operations.

Versions

1.1 and 1.2 are handled properly, which mostly means the difference in how the action is carried:

1.1	SOAPAction: "urn:doThing" as its own header.
1.2	action="urn:doThing" as a parameter on Content-Type.

The SOAPAction field shows the header line it will actually produce, so there is no guessing about quoting.

Faults

A SOAP fault is an HTTP 200 with a fault inside the envelope. Sendwire parses it and shows it as a fault — code, string, actor and detail — rather than leaving you to read XML soup and work out that the call failed.

From a script:

sw.test("no SOAP fault", () => {
  sw.expect(sw.response.soapFault()).to.equal(null)
})

Reading the envelope

// Inside <soap:Body>, as a plain object
const result = sw.response.soapBody().authenticateResponse.return

// Or straight to one element, wherever it is
const ticket = sw.response.xmlValue("ticket")
const all = sw.response.xmlValues("item")

Namespace prefixes are ignored, so these work whether the server wrote <return> or <ns2:return> — which varies between deployments of the same service and is not something you should have to care about.