Re: Myth of loose coupling

David,

>
> I thought I was understanding you until you compared using xml to driving
a
> car.  I don't quite see the value in some of the comparisons that are
> popping up.

Sorry, I just meant that even XML can be overkill sometimes, and having
a hard constraint that requires XML even when it is overkill wouldn't be
optimal.  But this was a minor point, overall.

>
> 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.


>
> As for the "Web" and XML, I've been part of a group working on a document
> that talks about what makes up the web architecture.  And XML is playing a
> bigger and bigger part of that, now that the group is spending less time
on
> URIs.  For example, section 3.3 [1], talks about all the properties that
are
> realized when using XML.

I'll check it out.

>
> I know what constraint some group of people think is the defining
> characteristic of the Web.  I also know that some people think that Web is
> completely defined by REST.  Believe it or not, I'm not sure that the two
> are completely the same, and I think it is XML that is the disconnect.  We
> better figure out soon whether XML is part of the Web or not.  Who knows,
if
> XML isn't part of the Web then some people will want the TAG to nuke the
XML
> activity.

Just to be clear, the constraint I meant was uniform identifiers.  Clearly,
XML
is not required for that.  Sorry if this sounds pedantic, but REST is an
architectural
style extracted from the deployed Web, so of course the two are not "the
same".
In particular, REST extracted what Roy felt were the underpinnings of
success,
not the failures.  But I don't see how XML can be the "disconnect" when it
integrates so nicely into the REST style.  Just not as a mechanism for
verbose
and risky modes of query (see above).

Walden

Received on Wednesday, 8 January 2003 09:10:07 UTC