Re: SOAPAction Proposal

I'm still trying to formulate my opinion, but I do notice that URI
fragment identifiers, path paramenters and queries (as you mention),
as well as things like xpointer seem to make this possible, or at
least worthy of consideration.

It's also interesting because one of our pseudo-requirements was to
make it possible to use XMLP from browsers. To me, one compelling way
to do this is with a normal GET HTTP request to a URI, with an XMLP
response.

Cheers,


On Fri, May 04, 2001 at 11:33:47AM -0400, Noah_Mendelsohn@lotus.com wrote:
> Mark Nottingham writes:
> 
> >> 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.
> 
> I am sympathetic in principle to this view, but doesn't it force us to:
> 
> a) decouple related methods on a conceptually single resource?  e.g. I 
> have a file resource, should I have separate URI's to which to send a 
> status check like (getLength) vs. a request like (read) or an operation 
> like (delete)?  I think it's reasonable to assume that one wishes to do a 
> variety of operations on a given resource.  Yes, in some sense the web 
> architecture is that everything, and this in principle every operation 
> should (be able to) have its own URI.  I'm less convinced, for the reason 
> just stated, that one would necessarily send the request to that URI. 
> Indeed, in the SOAP architecture, the namespace qualified name of the 
> operation (typically in the body) seems to serve the role of uniquely 
> identifying the nature of the service.
> 
> b)  Taken to its logical conclusion doesn't this require a separate URI 
> for every combination of parameters to the service?  After all, the value 
> of my bank account last week is a web resource, the value this week is a 
> (smaller) resource, etc.  If we really say that everything has a URI, then 
> surely there is a resource for last week's state and for this week's? 
> 
> So, I think it is indeed useful to be able to name services (or methods if 
> you like)  at a quite fine grain, to give them descriptions, etc.  I am 
> less convinced that just because a "method" is nameable with a URI that 
> one would necessarily send a SOAP request to that URI to invoke the 
> service.   Now, one way to deal with this (which I think would be cool in 
> principle) would be to encode the SOAP call after the "?" in a URI.  I'd 
> like to explore that as an option sometime, but in practice there are 
> length restrictions on URIs, etc. that make this somewhat problematic.
> 
> ------------------------------------------------------------------------
> Noah Mendelsohn                                    Voice: 1-617-693-4036
> Lotus Development Corp.                            Fax: 1-617-693-8676
> One Rogers Street
> Cambridge, MA 02142
> ------------------------------------------------------------------------
> 
> 
> 

-- 
Mark Nottingham
http://www.mnot.net/

Received on Friday, 4 May 2001 14:27:01 UTC