-
Notifications
You must be signed in to change notification settings - Fork 65
Description
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.