Hi,
Yeah - if you're hitting 3rd party endpoints you're kind of stuck with the URIs you've been supplied.
I have 1 rubbish idea that's a lot of hard work and inefficient 'I think' it will allow you to do your testing but its essentially hardcoding the requests.
Rubbish idea.
The example you've given is header and query parms. I was kicking around the idea of perhaps if you were using template parameters then not parameterizing the URI values - i.e. hardcoding the parameters values and create multiple requests in the 'Projects' (for each possible template parm value) section to get around this - obviously this could be a lot of work if there were a large number of possible values for each template parameter - but as I say - this would only work if they were template parms - not query or header parms.
Extending this rubbish idea, then I started thinking about if it was possible to do the same with your query parms. If you use the 'application/x-www-form-urlencoded' mediatype option for your requests and hardcode the query parms within the body of the requests - this will 'I think', allow you to have a query parm with 'the same' name value as a header parm. This wont work if the listening web service won't accept the Content-Type header of 'application/x-www-form-urlencoded' - but I asked a solution architect if a web service would inhibit the possibility of allowing the query parms in the body of a request and he didn't think the endpoint would care whether the query parms were in the body of the request rather than within the URI.
Only other thing I can suggest (still hoping someone else will have a good idea - I'm intrigued what the workaround for this could be) is you raise a SmartBear technical support ticket to see if SmartBear can answer this.
Sorry I couldn't be more help!
richie
