RE: Binding

> -----Original Message-----
> From: Mark Baker [mailto:distobj@acm.org]
> Sent: Sunday, January 05, 2003 2:48 PM
> To: Miles Sabin
> Cc: www-ws-arch@w3.org
> Subject: Binding
> 
> 
> 
> > Umm ... Mark, tell me when the URI,
> > 
> >   http://www.stockquotes.com/ibm/lastshareprice
> > 
> > gets "bound" in the REST version (ie. the server at 
> www.stockquotes.com 
> > becomes able to return representations in response to 
> requests for this 
> > resource). Or does it just appear by magic?
> 
> No no, different kind of "binding".
> 
> I mean the time the determination of which method to invoke on your
> service is made.

You seem to be beating on the RPC strawman, even after the WS-I has declared
him legally dead :-) Lots of people grant the point that RPC is not a
terribly scalable or robust architectural style for Web services.   We're
talking about the tradeoffs between POSTing an XML message that describes
some request to a web service vs. GETing a URI that identifies a request to
a web service. Both could be early or late bound onto the actual code ... 

Heaven help us, the hypoethetical www.stockquotesRus.com (there really is a
stockquotes.com!) might have a method getLastSharePriceOfIBM that a GET on
http://www.stockquotesRus.com/ibm/lastshareprice invokes ... or POSTing a
SOAP RPC message that looks like a getLastSharePriceOfIBM() invocation might
physically be bound to a SQL query that parses IBM out of the string and
looks it up.   These are (horrible) implementation strategies, but have
little to do with the web services architecture.

What DOES have to do with the WSA are the tradeoffs between communicating by
POSTing XML messages vs GETing URIs that do the same thing on the back end.
You have made an awfully strong case that the GET strategy is massively
superior, and I'd like to get those alleged advantages out for discussion.
The ones I recall offhand are consistency with Web mechanisms such as
bookmarks, consistency with the human-readable web (I could click on a link
that invokes a read-only web service and displays the result), and
consistency with the cacheing infrastructure (if a bazillion people GET the
URI whose respresentation is cached at various places on the web, it doesn't
cause a bazillion physical hits on the web server). 

It would also be nice to compare these advantages with the downsides ...
such as having to map any input parameters onto URIs subject to the URI
encoding and length constraints.... and with the advantages of POSTin XML
(e.g., leveraging the XML infrastructure, and the ease of mapping a "one
size fits all" solution to procedural code, alternative transport protocols,
etc).

Received on Sunday, 5 January 2003 15:31:40 UTC