RE: SOAPAction Proposal

I agree that distinct services should have distinct URIs but not that
this necessarily maps to all message types require different endpoints.
The rule is that "all that has identity" on the Web has a URI. However,
because one has identity, it is still possible to accept multiple
message types.

HTTP fundamentally supports this by allowing an open-ended set of
request methods - the only ones that are required is GET (and HEAD)
because they are special. The implicit mechanism that one has when
reading a URI from a bus etc is "GET".

The real issue is that URIs are independent of the service they provide,
the format of the messages that it accepts, any natural language that
they might use etc. Looking at two typical examples:

	http://www.henrik.com/cgi-bin/weather
	http://www.henrik.com/foo.html

Tells me nothing about whether the first might be implemented using a
CGI script or not and nothing about whether the format of foo.html is
"text/html". The server could have the former name return a static HTML
page and the latter be a CGI script.

Henrik

>One of the comments that has come up re: SOAPAction and SOAP
>services in general is that making multiple methods/services 
>available on the same URI (e.g., depositMoney, withdrawMoney on
>http://www.bank.com/service) is fundamentally at odds with the 
>Web architecture, because all services/resources available on 
>the Web (including Web Services) should be able to be identified by a
>(singular) URI.
>
>Therefore, an alternate proposal would be to drop SOAPAction 
>and require that methods/services have distinct service URIs.
>
>Personally, I think there is still value in separating the 
>service location (transport URL) from the service identity, 
>until we live in a URN-resolvable world (not holding my breath 
>just yet, tho some of the recent work is interesting). 
>However, I do think this might make sense, generally; while 
>SOAPAction might still have value, the argument above still 
>may be valid, and the right thing might be to require a 1-to-1 
>relationship.

Received on Monday, 7 May 2001 12:27:16 UTC