RE: Why GET is an application semantic

> From: Mark Baker [mailto:distobj@acm.org]
> Sent: Wednesday, June 19, 2002 7:18 PM
> To: Joseph Hui
> Cc: www-ws-arch@w3.org
> Subject: Re: Why GET is an application semantic
> 
> 
> Darn, we're not making much progress here.  One last change of
> strategy before admitting defeat. 8-)

Nah, there is no defeat to speak of here. :-)
Either method IMO would do.  I wasn't set out to convince
anyone my way was better, just to bring up there was yet
another choice designers may consider.  

> On Wed, Jun 19, 2002 at 02:28:51PM -0700, Joseph Hui wrote:
> > > Why do you need "get1" or "get2"?
> > 
> > For two functionally different implementations.  
> > 
> > As I had said above (previously), one may squash the
> > two into one generic function and parameterize the
> > realtime/delayed difference into an option for the caller.
> > It's a designer's choice.
> 
> Yes, but the implications for each choice on the ability to deploy at
> Internet scale are tremendously different in each case.  So much so,
> that one is deployable on the Internet, and one isn't, in my opinion
> and observation.

I'd done it (developed and deployed, though not with stock quote apps)
the way I described, and it worked well every time. 
I think Yahoo did it in similar ways with their stockquote websites.

> By agreeing on the methods/semantics, and letting the identifier
> vary without affecting those semantics, you do two extraordinarily
> important things for the ability to deploy on the Internet.
> 
> - enable a priori communication; see a URI, you know you can 
> invoke GET
> on it
> 
> - establish a trustable contract between components in the
> architecture, which is what is needed for IT folks to let messages
> pass through their firewalls

The IT folks, if they prefer the "pin-hole" security policy/philosophy,
would have to set the granularity of HTTP filters beyond TCP port 80
in either case though,

> If you put the method in the URI, then that bypasses the contract.
> A firewall can no longer assume that GET is a safe operation, and
> therefore firewall administrators are incentivized to block the
> traffic because the semantics aren't visible to them; you can't
> trust what you can't see.
> 
> > > A URI identifies a resource - something with state
> > > and identity, like an object.
> > 
> > A web resource, "like an object" as you said, can have an operation
> > aspect to it.  As an object can encapsulate data and method in its
> > definition, why can't a URI?  What am I missing?
> 
> Because a URI just identifies the object, it isn't the object.  It's
> an identifier, like "Joseph Hui", not an action like "Pay Joseph Hui".
> 8-)

A URI can be used as an object identifying another object.  
This is not a hack; nor am I contriving with words. 
Following up with your example:
see "Pay Joseph Hui" in one object, invoke a PAY method in
another object, with "Joseph Hui" as an input parameter value
for the PAY method.  

I think we've beaten the horse to dead, and a dead horse ain't
gonna go far no matter how hard we continue beating it.
So I'll settle for the "design choices, or trade-off" and leave
it at that.

Good night,

Joe Hui
Exodus, a Cable & Wireless service
=======================================================

> 
> MB
> -- 
> Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
> Ottawa, Ontario, CANADA.               distobj@acm.org
> http://www.markbaker.ca        http://www.idokorro.com
>

Received on Wednesday, 19 June 2002 23:11:56 UTC