RE: Myth of loose coupling

> -----Original Message-----
> From: Walden Mathews [mailto:waldenm@optonline.net]
> Sent: Wednesday, January 08, 2003 9:09 AM
> To: David Orchard; www-ws-arch@w3.org
> Subject: Re: Myth of loose coupling
> 
> 
 
> 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.


Hmmm.  I've been trying to reconcile the RESTful and SOAP/WSDL web services
perspectives by asserting that it's NOT a paradigm shift, but an engineering
decision about optimizing specific scarce resources in specific scenarios.
SOAP/WSDL tends to optimize programmer resources when there is existing code
on both sides to integrate over the Web (the most typical business case for
this technology today), REST tends to optimize re-use of exisiting Web
resources, integration with Web technologies, and discovery in much more
loosely coupled (and written for the Web) applications. I think that's close
to the position I thought you were taking at the beginning of this
incarnation of the thread, i.e., that there was a big middle ground between
the REST and SOAP/WSDL approaches.

Sure, the *extremes* of a pure SOAP-RPC and a pure hypermedia/SW REST
architecture could be thought of as different "paradigms". Still, as several
of us point out repeatedly, even hard-core WS people acknowledge the
scalability problems and fragility of the pure RPC approach. Likewise (ahem)
the pure hypermedia/Semantic Web approach to addressing the use cases that
Web services people talk about [as opposed to spiders, cows, and
circles/rectangles :-) ] looks a bit vaporous when it comes down to actual
implementations in the field.   So as a practical matter today, we're all
somewhere in the middle.

So, I (if that was me who said "these parameters have to be sent somehow")
was referring to "parameters" in a very abstract sense, not as arguments to
a remote procedure call, e.g. "query parameters", "business process
parameters", etc. I do agree that as a best practice guideline, "long lists
of parameters in queries" is a symptom of a too-tight  coupling or a
too-desperate attempt to throw some stuff at the service and hope it can
make sense out of it. 

So, my bottom line remains: let's mine REST for best practice guidelines and
suggestions how to build web services that scale to the Web.  Let's not get
caught up ideological struggles between contending paradigms.

Received on Wednesday, 8 January 2003 09:46:41 UTC