Skip to content

Is imposter or a plugin able to validate a SOAP request using a WSDL file? #718

@plocket

Description

@plocket

I'm somewhat new to services and I'm very new to SOAP. I tried to test whether imposter, with the SOAP plugin, could tell me if my request was badly formed based on the schema that the WSDL and XSD files describe. I created this config:

plugin: soap
wsdlFile: myFile.svc.wsdl

# # I think this is for the OpenAPI plugin and it didn't change anything
# validation:
#   request: true

resources:
  - operation: GetThing

When I sent a well-formed request, imposter generated a response that looked right to me. Then I sent a badly-formed request (missing a <Header> that the WSDL schema requires),:

<ns0:Envelope
    xmlns:ns0="http://schemas.xmlsoap.org/soap/envelope/"
    <!-- and so on -->
    >
  <ns0:Body>
    <ns1:GetThing />
  </ns0:Body>
</ns0:Envelope>

I was expecting to get back a response that the request was badly formed, but I got the same response as the well-formed request. This implies to me that I'm doing something wrong or that imposter (or the imposter SOAP plugin) doesn't read the schema deeply enough to fully validate the request.

I've searched the docs for information on this as well, but haven't found anything that explicitly said this one way or another. At "using the plugin" I found the following:

A great way to use this plugin is to take advantage of the request/response types defined in the WSDL types or referenced XSD files. These allow the mock server to generate a response without custom configuration or code, just by parsing the schema of the response message specified in the WSDL types/XSD.

This plugin will match the operation using a combination of:

matching URI/path
matching HTTP method
matching SOAPAction (if required)
matching XML schema type of the root element within the request SOAP envelope body

Imposter will return the first response found that matches the above criteria.

This could possibly mean that this tool is able to fully generate a response dynamically based on the request using the WSDL files and thus would be able to validate requests. Alternatively, this could mean that to get that kind of fine grained detail I'd need to use a different method than just the WSDLs. For example, I could hard-code to match against features of the request and specify a custom response file of my own. If that's the case, that would mean that this tool isn't meant to apply the WSDLs on such a deep level.

Regardless of the answer, thanks for maintaining this tool.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions