Thanks for the reply -
1. The post to which you refer is this post :) - reading through, it looked to me like there was a bunch of overriding methods (e.g. getServiceInputs) and workarounds involved - if that's not the case any more - great :)
2. I was imagining a RESTful DataSource (like David's that I referenced) which would allow substitutions of DataSource fields into the URL - is this what you mean when you refer to pathSegmentFields? Given that this approach is quite common in a RESTful application, this would be a good addition, and shouldn't break the existing API.
3. Ok - took me a second to identify the relationship - for others, the DSRequest object that is a parameter in the transformRequest() method being overriden in point 2 extends RPCRequest.
4. I hadn't considered that the browser would be a barrier - I guess you need the browser API to allow you to set the OPTIONS method? I had assumed that given 15 years or so, and one protocol to work with, and only a handful of methods, that the browser would actually implement the protocol :) Naive I guess.
5. Urgh. WSDL. :) I did realise after I submitted the comment here that the XPath usually won't be enough to reconstruct the message reliably - you probably need a schema (which you should get with WSDL).
So I guess my feature request has been boiled down to requesting support for datasource field substitutions in the 4 method URL's. This would be a welcome addition - thanks,
Colin
1. The post to which you refer is this post :) - reading through, it looked to me like there was a bunch of overriding methods (e.g. getServiceInputs) and workarounds involved - if that's not the case any more - great :)
2. I was imagining a RESTful DataSource (like David's that I referenced) which would allow substitutions of DataSource fields into the URL - is this what you mean when you refer to pathSegmentFields? Given that this approach is quite common in a RESTful application, this would be a good addition, and shouldn't break the existing API.
3. Ok - took me a second to identify the relationship - for others, the DSRequest object that is a parameter in the transformRequest() method being overriden in point 2 extends RPCRequest.
4. I hadn't considered that the browser would be a barrier - I guess you need the browser API to allow you to set the OPTIONS method? I had assumed that given 15 years or so, and one protocol to work with, and only a handful of methods, that the browser would actually implement the protocol :) Naive I guess.
5. Urgh. WSDL. :) I did realise after I submitted the comment here that the XPath usually won't be enough to reconstruct the message reliably - you probably need a schema (which you should get with WSDL).
So I guess my feature request has been boiled down to requesting support for datasource field substitutions in the 4 method URL's. This would be a welcome addition - thanks,
Colin
Comment