Re: whenToUseGet-7 Making SOAP Restful

Hi again,

> > But IMO, trying to build something HTTP-like on top of SOAP, which in
> > turn will often be on top of HTTP, is quite impractical and unnecessary.
> > It's true that HTTP's extensibility and processing models aren't as rich
> > as SOAP's, but also IMO, these small improvements are no where near
> > enough to justify the huge cost of deploying such a solution.
> 
> Hmmm.... not sure I was trying to build "something HTTP-like" on top of
> SOAP.

Well, that's what I would call both your and Noah's attempts to do a
GET via SOAP.  I mean, once you've got GET within the SOAP envelope, you
might as well do PUT.

"GET" is also more than the retrieve semantic.  There's conditional GET
(If-*), piecemeal GET (ranges), negotiated GET (Accept-*), etc...  If
the method is within the SOAP Envelope, then you'd need to reinvent all
those mechanisms as SOAP headers to apply to the SOAP Envelope.  HTTP
content negotiation (and other features) "underneath" would only apply
to SOAP itself.

> One of the 'complaints' levelled against the current HTTP binding in
> the SOAP WDs is there are no circumstances under which it uses HTTP GET. I
> was offering a slight modification to Noah's suggestion, which at least to
> me, seems to provide a natural way integrate GET into the request-response
> MEP. As with Noah's suggestion the burden of generating the request URI
> falls on the SOAP application, ie. it doesn't provide a scheme for URI
> encoding the contents of a SOAP message...

Understood, but I would call it far from "natural".

> I was hoping that you might respond along the lines of... that looks
> interesting... but apparently not.

I think it's as interesting as Noah's proposal. 8-)

But seriously, Noah's example (with or without your amendment) is
interesting, because it demonstrates the different ways in which SOAP
can be used.  Practically though, I see no value to it.  Sorry! 8-(

> As I have said before, that seems to me very much like treating SOAP as a
> media-type and the protocol is then HTTP with representations that just
> happen to be contained in SOAP envelope. [Observation, not a complaint].
> There would be no need for a SOAP/HTTP binding, GET/PUT/HEAD/DELETE/POST all
> available as specified in HTTP. Equally, no sense of an independent
> abstraction of what SOAP is.

We've been over that before, no need to bore the TAG with it. 8-)

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@planetfred.com
http://www.markbaker.ca   http://www.planetfred.com

Received on Friday, 26 April 2002 12:08:19 UTC