Re: Generic URI things

Mark Baker wrote on 01/08/2003 09:57:11 AM:

> 
> On Wed, Jan 08, 2003 at 10:16:57AM +0000, Miles Sabin wrote:
> > > Yes, but - and I admit I've done a poor job at explaining this - the
> > > "a priori" information we're talking about here for the RESTful
> > > approach is just the same a priori information needed to understand 
a
> > > schema. There's nothing else that is needed - check above.  With
> > > WSDL, you need the a priori information of how to process the 
schemas
> > > in use *and* the a priori information of the interface to that data.
> > >
> > > Do we agree to that last point, even if we may not agree on the
> > > impact to the properties of the respective architectural styles?
> > 
> > Absolutely not.
> > 
> > I assume that when you say "schema" you mean it in the sense of DTD, 
W3C 
> > XML Schema or RelaxNG.
> 
> Right.
> 
> > I'm afraid this is just wrong. Given a URI and a schema and just 
generic 
> > URI and schema handling code, the _only_ things you can do are generic 

> > URI and schema things
> 
> Absolutely true!!
> 
> > ... ie. nothing much beyond dereferencing and 
> > validation.
> 
> Absolutely false!!
> 
> I'm sorry, I wasn't aware that you believed this.  Had I, we could
> probably have saved lots of time!
> 
> Other generic things you can do include;
> 
> - setting the state of some resource (PUT)

Whoa, back up the bus! Where did the agent get the understanding needed
to populate an instance of a document defined by the schema? Sure, I can
randomly populate the elements and attributes with values that validate
against the schema, but that is no different that putting an infinite 
number of 
monkeys in front of an infinite number of typewriters and expecting one
of them to eventually produce a copy of Hamlet.

You have made quite a leap here. Miles did not include understanding
of the semantics of the schema in his equation. Just the schema and
generic schema processing and the URI and generic URI processing.

> - submitting some data for processing (POST)

ditto.

> - removing data (DELETE)

I'll grant you that one.

> - locking a resource for private access (WebDAV LOCK)
> - subscribing to the resource to be notified when it changes state
> (Waka/Idokorro/KnowNow MONITOR/WATCH)

Hmmm... and where is the IETF RFC that defines these methods? They appear 
to
be proprietary in nature. This is not consistent with the uniform 
interface
constraint. This is at best coincidence. Note that I too could define a 
MONITOR
method and have it mean something subtly or radically different than you 
have 
intended. Wouldn't you be surprised if my implementation of the MONITOR 
method
were to deliver a monitor lizard to your front door because it used the 
Semantic
Web to infer your home address from the URI that you gave me as the 
callback!
Yikes! (watch out, they bite!)

Further, how did the meme for the meaning of MONITOR/WATCH (hmmm... which 
to choose!)
find its way through the Web and into my HTTP client and server software? 
How would 
my software know that MONITOR required a callback URI to be included in 
the request 
message? How would I know what manner of representation I might expect to 
receive for 
the MONITORed resource?

Given that anyone can devise HTTP methods of their choosing, how is this 
ANY different
than is the case for what you have been ranting against ad nauseum? 

What if I were to define an HTTP method called:
 
LOOKATTHEFIRSTCHILDELEMENTOFTHESOAPBODYCONTAINEDINTHEENTITYBODYOFTHISREQUEST
Hmmm??? Anything in REST that constrains against this? Anything in RFC2616 
that precludes
this sort of silliness? Not last time I checked...

Heck, I could define a method called GETSTOCKQUOTE for that matter. Not a 
good idea, I fully
agree, but again, REST doesn't constrain against stupidity or ineptitude 
of the application 
designer.

The fact that there seem to me two (at least) camps (the MONITOR and the 
WATCH camps)
who will likely need to get together to agree on a compromise on the name 
and specifics
of the MONITOR/WATCH method isn't much different than the situation that 
those who
are beginning to deploy Web services that have similar intent, but subtly 
different
input/outputs, etc. Of course, it is the standardization efforts that will 
make all of this
a success, just as it has been the open standradization of the HTTP 
protocol, HTML, etc that
has made the Web a success.

Would fewer, more generic methods be preferable to a gazillion? Of course! 


> 
> etc..
> 
> "generic URI things" are what the uniform interface is all about.

See above.

> 
> I'll hold back on responding to your other points, because IMO, this is
> the whopper.
> 
> What say ye, fan of the Pi-Calculus?
> 
> MB
> -- 
> Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
> Web architecture consulting, technical reports, evaluation & analysis
> 

Christopher Ferris
Architect, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
phone: +1 508 234 3624