W3C home > Mailing lists > Public > www-ws-desc@w3.org > April 2004

RE: Issue 54: allowing arbitrary HTTP methods (related to issue 147)

From: David Orchard <dorchard@bea.com>
Date: Wed, 21 Apr 2004 14:25:44 -0700
Message-ID: <32D5845A745BFB429CBDBADA57CD41AF06E2012E@ussjex01.amer.bea.com>
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?


> -----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 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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:54:48 UTC