Re: Why GET is an application semantic

Darn, we're not making much progress here.  One last change of
strategy before admitting defeat. 8-)

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.

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

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

Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.     

Received on Wednesday, 19 June 2002 22:08:17 UTC