- From: David Orchard <dorchard@bea.com>
- Date: Wed, 21 Apr 2004 14:25:44 -0700
- To: "Hugo Haas" <hugo@w3.org>, <www-ws-desc@w3.org>
Hugo, why can't we do as you suggest and add put and delete, and then define default behaviour for extensibility, as I proposed? Dave > -----Original Message----- > From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]On > Behalf Of Hugo Haas > Sent: Friday, April 16, 2004 12:14 AM > To: www-ws-desc@w3.org > Subject: Issue 54: allowing arbitrary HTTP methods (related to issue > 147) > > > Following our discussion about support of WebDAV and the HTTP > Extension Framework in the HTTP binding, I have taken an action to > look into why the current binding doesn't allow one to specify the > HTTP method directly in the binding, and if it's possible to change > it. > > As it stands, the HTTP binding lets you specify which HTTP method in > an indirect manner: > > <http:operation method="post|get|form-data-post" /> > > Those binding methods are specified in table 3-1 in section 3.1.1.1 of > Part 3. They correspond to an HTTP method, an input and output > serialization, a set of possible MEPs, operation styles. The bottom > line is that, in order for a method to be supported by the binding, it > needs to be in this table. > > The proposal made yesterday by Sanjiva was to specify the HTTP method > directly instead: > > <http:operation method="GET|POST|PUT|..." /> > > The advantage of this is that one could specify here any HTTP method, > e.g. PROPPATCH or M-GET. > > However, table 3-1 shows that knowing the method alone isn't > sufficient. For example, there are two ways of serializing the input > of a POST: application/xml or multipart/form-data. So we would need to > add another attribute for input serialization. E.g., for POST: > > <http:operation method="POST" > input="application/xml|multipart/form-data" /> > > We step here into issue 147, which is about allowing arbitrary content > type. > > I believe that issues 54 and 147 boil down to a trade-off between > simplicity and extensibility. > > The current situation is simple: a fixed set of usable HTTP methods is > defined in table 3-1, and this table also defines their input and > output serializations. If somebody wanted to use WebDAV or the HTTP > Extension Framework, they would need to define a binding for them. > > If we move to a more flexible solution, then table 3-1 will contain > the following information: > - if the HTTP method MMM is specified, then > only the following serializations are valid (e.g. for GET only > application/x-www-form-urlencoded will be allowed) > - if the HTTP method MMM is specified and if the operation style is > sss, then the following input serializations can be used (e.g. for > POST to use multipart/form-data, Multipart style is needed). > > Other HTTP methods would be allowed, but we wouldn't be able to > constrain the operation style nor the serialization, e.g. to have an > M-GET binding operation which actually makes sense. > > I am afraid that such a generalization is going to make the HTTP > binding more complex for most of the use cases. Our charter requires > us to provide a binding for GET and POST, and to look into PUT and > DELETE. In light of the proposal I made for issue 64[1] and of the > SOAP Web Method Feature, adding PUT and DELETE to our current binding > is easy and we should do it by adding the two lines I proposed in [1] > to table 3-1. However, allowing for any method looks like it is going > to make our spec more complex for the simple cases that pretty much > everybody will use. > > I will add that in order to fully support the HTTP extension > framework, we would need support for arbitrary headers (issue 55), or > better, have support for mandatory and optional extensions built > directly into the bindings, but the latter is definitely out of scope > for us. > > Note that we may need to make some progress on 147 before actually > closing issue 54, as they are connected. > > Regards, > > Hugo > > 1. http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0031.html > -- > Hugo Haas - W3C > mailto:hugo@w3.org - http://www.w3.org/People/Hugo/ >
Received on Wednesday, 21 April 2004 17:25:47 UTC