Mark Baker wrote: > > I think it should be ok to default the MEP to .../soap-response/ when > GET is specified as the Web method, since that's all SOAP 1.2 specifies. > But the developer should be able to specify a different MEP too.
Glen Daniels: "when GET is specified"... what Axis API would you envision for this semantic? >>I guess that depends on what our goals are. If we are looking at >>defining point to point requests which presume that developers are >>comfortable coding at a relatively low level interface to achieve this >>(pretty much the current web monkey developer community), then the above >>achieves this goal. > > Yes, that is my goal, so it's good to hear that's what you had in mind > above. I just wouldn't call it a "relatively low level interface", but > perhaps that's simply a nomenclature issue. In cases where the URL is opaque, I agree. I'm primarily talking about cases where constructing a URL based on concatenation and encoding. >>Just recognize that the same toolkits will also be providing WSDL >>tooling that will make it easier and less error prone to define the now >>more traditional HTTP POST requests. So while the above support would >>enable HTTP GET requests, I fear that many (most?) will follow the path >>of least resistance and continue to do HTTP POST. > > That's certainly possible. But in my experience, GET can be quite > infectious. WSDL-over-GET caught on like wildfire, for example. > I guess we'll see how it works for the service itself. WSDL-over-GET is an idempotent and side effect free method with zero arguments. For services that match this signature profile, I would agree with you. >>For this to change, we will need to find some way of providing enough >>metadata so that toolkits can automatically and correctly identify the >>resources associated with such requests as >>"updateQuantityInStock(PartNumber="123", NewQuantity="200") and >>"getQuantityInStock(PartNumber="123"). Both of these examples are from >>the SOAP 1.2 spec, part 2, section 4.1. > > In general, it's not automatable, because deciding what's a resource and > what isn't is a design decision. But if you're up for it, I'd be > interested to see how far you could go with that. 8-) Sorry, I expressed myself imprecisely. I'd like the author of the web service to be able to express enough semantics in their web service description as to how the URL is to be constructed that various toolkits can automate the mapping of this into their target platform / language. - Sam Ruby
