Re: Myth of loose coupling

+1.  I was going to respond to Mike, but this says more or less what I
wanted to say.

Though I detest the expression, there really is a "paradigm shift" to
understanding why GET+URI is superior to POST+method.  For most people
coming from a CORBA/DCOM-like background (like myself), it takes a
"eureka moment", if you know what I mean.

On Wed, Jan 08, 2003 at 09:09:08AM -0500, Walden Mathews wrote:
> > Isn't the trade-off between XML and URIs when invoking services pretty
> > clear?  I cannot use GET and pass xml data.  So I'd have to encode up all
> my
> > data in the URI.  Darn, length limits, no ways of doing modularity, have
> to
> > use html URL-encoding.  Or I could send the XML data as part of a POST
> > request.  Say I've got a conversation ID, or a username/password, or
> ticker
> > symbol, or whatever.  These parameters have to be sent somehow.  URI, SOAP
> > header, XML document, HTTP Header, some place has to have it.
> 
> This is worth talking about more.  I note that Mike Champion made a similar
> assertion to Mark Baker yesterday:
> 
>     "Well, sorta.  I see your point anyway.  The a priori information on how
> to
> access the specific service is encoded in the URI in REST, and in WSDL for
> the conventional web services approach.  URIs are a bit easier to paint on
> the side of a bus (although realistically the URI to do anything interesting
> with a Web service will be long and ugly) than WSDL documents are, but WSDL
> documents are non-opaque, contain more information, and have all sorts of
> programmer-friendly tools that work with them in conjunction with XML
> schemas, Java classes, etc.  URIs leverage the Web more fully, WSDL
> leverages XML more fully.   Also, we're only (AFAIK) talking about read-only
> Web services here; more elaborate a priori information on the format of the
> data to PUT or POST will be needed in either approach.  WSDL provides a way
> to do that, it's unspecified (at present) in REST."
> 
> It seems the assumption here is that re-formulating the XML material
> of a Web services request into the GET URI would somehow make the service
> RESTful.  It doesn't, as long as the request string has the meaning of the
> query encoded directly in it.  That's still what Mark calls "RPC".
> 
> The crux of the matter lies in this statement (from above): "These
> parameters
> have to be sent somehow."  There's a paradigm shift in understanding why
> that's not quite true when you use a web of resources more optimally to
> solve
> your problem.  I'm not saying you never need to send parameters, so please
> avoid an absolute interpretation here.  I'm saying that long lists of
> parameters
> in queries is a symptom of the client taking too much risk in
> second-guessing
> the capabilities of the service, a practice which can backfire under
> internet
> conditions.  I'll stop here and see if there is any comment or question.

-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis