Re: SOAPAction Proposal

Scott Seely wrote:
...
> This makes me wonder if SOAPAction is even necessary.  Given that
> SOAPAction is HTTP specific, I believe you can get all the benefits of
> SOAPAction through use of the URL.  You can send object/method hints in
> the URL-we already do that with CGI type technologies without ill effect
> (think ASP, JSP, etc.).  Web admins already understand how to filter on
> URL, so you don't have to teach them about the peculiarities of SOAP.  I
> know the argument for the header-it tells that this is supposed to be a
> SOAP message.  The problem with this is that it never mattered for CGI
> stuff (I don't think a CGIAction field exists and no one I know wants
> one).  

(Note that CGI is not a network protocol, and, more specifically, it is 
not a protocol layered on top of HTTP.  (It's just an interface between 
an HTTP server and separate scripts that help implement the server's 
function of returning some HTTP response.)

Therefore, CGI's not anything that HTTP clients or firewalls would care 
about.  (They might care about which URI is requested, but they won't 
care whether the HTTP server services that URI using CGI, servlets, 
hard-coded C, or whatever.) 

Therefore, there was no need to identify that CGI would be used to service 
the request.)



>... You would still
> need some way of mapping the URL to the message.  Lots of
> implementations route on the GET header and ignore the SOAPAction.
> "Monolithic endpoints" are giving way to special purpose endpoints.
> 
> For example, assume an object named foo has three operations: bar1,
> bar2, and bar3.  Instead of having the endpoint for all of these
> operations be
>             http://someurl/foo <http://someurl/foo>
> and then routing on SOAPAction, I could also do this:
>             http://someurl/foo#bar1
>             http://someurl/foo#bar2
>             http://someurl/foo#bar3 <http://someurl/foo#bar3>

You probably want "http://someurl/foo?bar1".  (A URI-reference fragment
identifiers isn't (normally?) sent to the server; a URI query component
is.)

> Voila, I know the intent because my HTTP GET header will ask for
> /foo#bar1 and I will have intent already without any new machinery.  And
> no, this doesn't feel like a kludge-I already do nastier things with ASP
> pages.


Actually, why limit ourselves to the query component?  Why not use 
segments or segment parameters?

One could define "http://someurl/foo" as a root URL for the endpoint, 
accept all URLs of the form "http://someurl/foo/...", and dispatch on 
the part after the root URL.

(I'm thinking in terms of Java servlets:  In addition to registering 
a servlet to handle a given URI path ("http://host/foo" (but not 
"http://host/foo/x"), you can register a servlet to handle a whole 
subtree of URL paths ("http://host/foo" and anything "under" it).  If 
you send a request to the URI "http://host/foo/x", the server calls
the servlet with a relative path of "x", from which it can dispatch
however it wants to.  

(CGI scripts have the same capability.))

Alternatively, one could use URI segment parameters 
("http://someurl/foo;action=doIt;param2=23").



Are these options (URI path subtrees or segment parameters) that can be 
considered, or will XMLP have to use simple, single-URL endpoints?



Daniel
-- 
Daniel Barclay
Digital Focus
Daniel.Barclay@digitalfocus.com

Received on Thursday, 3 May 2001 12:20:06 UTC