On Sun, May 06, 2001 at 03:12:08PM -0400, Keith Moore wrote:
and client APIs. It also keeps HTTP servers from having to know
specifically whether a particular URI corresponds with a SOAP
request (in which case it might have to look at the SOAPAction header
in order to know how to handle it) or not (in which case the SOAPAction
header should be ignored).
Yep; seems to me that Content-Type ss more appropriate for dispatch,
if doing it in a header is desireable.
ugh. only if you must. the URL is *far* better for this purpose.
The name of the SOAP service should *not* be inferred from the XML
namespace used to describe the request. This would make it impossible
to have multiple services that accept identically formatted requests.
The idea is that the identity (i.e., "this is a stockquote service")
is implied by the namespace, and therefore is useful for firewall
admins, etc., so they can work at the granularity of a service type.
The location of the service is still carried in the HTTP
request-line. SOAPAction isn't intended to uniquely name services.
I can see why you might want firewalls to be able to filter certain
kinds of data - having everything tagged in XML might allow firewalls
to prevent inadvertent leakage of data of types known to be 'sensitive'
via any of several protocols. But I don't think you really want to
conflate the name of the data structure with the name of the service,
and probably not even with the 'type' of the service. The type of
the service and the type of data presented to the service should be
kept separately.
Keith
p.s. One thing that really concerns me about the SOAP approach is what I
call firewall escalation - the chief justification for using HTTP as a
substrate for SOAP is to allow it to operate through existing firewalls,
but one of the consequences of SOAP is likely to be that firewalls become
more complex (and more error-prone) due to a need to dig deeper into the
HTTP payload. This degrade service for all uses of HTTP. So I think
SOAP should be designed, to the extent possible, to avoid encouraging
such escalation.
And if it ends up requiring changes to HTTP after all, and/or changes
to existing firewalls, then it should be declared to be a different
protocol, with a different default port, with a different URI prefix.
That way, the firewall measures that get put in place for SOAP don't
end up affecting use of ordinary HTTP.