- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 3 May 2001 11:56:12 -0700
- To: Martin Gudgin <marting@develop.com>
- Cc: XML Protocol Comments <xml-dist-app@w3.org>
I'm going to attempt to regurgitate some of the conversation we had after the call, despite the fact that I haven't slept between then and now... ;) 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. On Thu, May 03, 2001 at 05:06:55PM +0800, Martin Gudgin wrote: > I've been reading the mails on SOAPAction, there seems to be some sentiment > for the idea that the value of SOAPAction should reflect some information in > the body of the message. Here is a proposal for discussion; > > The value of SOAPAction *must* be the namespace URI and local name of the > first element child of soap:Body separated by a #. If the value of > SOAPAction does not contain that value the server *must* generate a fault. > > e.g. > > POST someuri HTTP/1.1 > Content-Type: text/xml > Content-Length: nnnn > SOAPAction: myuri#myelement > > <soap:Envelope xmlns:soap='uri for soap' > > <soap:Body> > <m:myelement xmlns:m='myuri' /> > </soap:Body> > </soap:Envelope> > > Note that currently SOAPAction can be anything, it doesn't need to reflect > any piece of information in the body of the message. This proposal is > similar ( if not identical... ) to the SOAPMethodName in SOAP 1.0[1] > > Flames, comments etc. to the usual address, > > Martin Gudgin > DevelopMentor > > [1] http://www.soaprpc.com/mirror/ietf/draft-box-http-soap-01.txt.html > -- Mark Nottingham http://www.mnot.net/
Received on Thursday, 3 May 2001 14:56:21 UTC