Mark Baker wrote: > >> No standard means of representation of arguments or method names is >> provided by this specification. > > Does that matter? > > From the client POV, the developer provides the URI via > Call.setTargetEndpointAddress(). GET is invoked directly on that, the > same way it would be if you typed that URI into a browser. > > From the server/service POV, I don't see that it makes a difference > either.
For all idempotent and side effect free methods with zero arguments, sure. The value of REST is that it provides a Simple Access Protocol to Objects which it refers to as Resources. From a REST and HTTP point of view, URIs are opaque. The value of SOAP is that it provides a REpresentation suitable for the Transfer of States. SOAP 1.2 Part I Section 5 defines the infoset for the state to be transferred which it refers to as a SOAP message. The concern I have is that there is no representation provided for bindings of such infosets on the sending side when desired web method to be used is HTTP GET. What is needed, in my mind, is something analogous to http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.13.1 . Can you imagine how much less useful HTML FORMS would be if there was no standard means of representation of control name/control value pairs provided by the HTML specification? And if each browser and server application were free to define their own? Section 4.1.1 of the SOAP 1.2 spec implies that such is out of scope for the SOAP specifications, and hints to WSDL as the appropriate place. I can certainly accept this, but lets go full circle and reexamine your first post to this mailing list: > I've had a look through the archives, and haven't found any discussion > about what the Axis team is thinking about doing to support the > "Web Method Specification Feature"[1] of SOAP 1.2 when bound to HTTP. > I'm specifically interested in GET support. Perhaps we should be looking to the Web Services Description Working Group to provide more details first? Thanks for listening. - Sam Ruby
