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/