W3C home > Mailing lists > Public > www-ws-arch@w3.org > July 2002

RE: A REST challenge

From: David Orchard <dorchard@bea.com>
Date: Wed, 17 Jul 2002 15:26:00 -0700
To: "'Paul Prescod'" <paul@prescod.net>, <www-ws-arch@w3.org>
Message-ID: <013b01c22de0$edd097f0$0100007f@beasys.com>

> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Paul Prescod
> Sent: Tuesday, July 16, 2002 4:16 PM
> To: David Orchard; www-ws-arch@w3.org
> Cc: 'Francis McCabe'; 'Mark Baker'
> Subject: Re: A REST challenge
> David Orchard wrote:
> >
> > Paul asked a question about how one would do correlation in
> SOAP...  Well -
> > aside from a small tech problem with 3 versions being
> retrieved :-( - we've
> > got something at
> http://ftpna2.bea.com/pub/downloads/SOAPConversation1_0.htm
> >
> > We can talk about implementation experience rather than theory.
> I'll point out that correlation using URIs is also done
> commonly in the
> real world. Since that URI is a 404 perhaps you could give
> some concrete
> syntax examples of what you propose.

Sorry 'bout that, the URI should work now.

> > .... So the XML extensibility model is
> > utilized.  You can imagine doing exciting things like
> adding security
> > information - when calling back, use this particular
> security token - and
> > others to the XML model.
> Sure, we do that stuff with REST/HTTP all of the time. All
> REST says is
> that you don't invent some non-standard conversation ID
> concept. If you
> need to reify conversations then make them URIs and allow both parties
> and third parties to inspect them using standard tools.
> According to the
> TAG:
> "An important principle of Web architecture is that all important
> resources be identifiable by URI."
> I'm sure you'll agree that a conversation is an important
> concept. If it
> is, then it should be a URI-addressable resource.
> Furthermore, it should
> be addressable by HTTP so that it is inspectable and introspectable
> using GET.

I'm extremely familiar with the TAG finding, and you know that.  I was
...startled... that you chose to use that quote in a message to me.  The
keyword that you don't seem to want to grasp is "important".  And who
defines important.  Also the complete circularity of the argument.
Position: use URIs for important resources.  What are important resources?
Important resources are ones that need to be GETtable, that is have a URI.
Use URIs for important resources, and important resources are those
resources that have URIs.  voila, circularity and the URI eats it's tail.

A conversation is an important concept.  Therefore a URI for where to find
at least one definition of a conversation protocol is provided.  That does
not mean that an individual instance/thread of a conversation is necessarily
an important resource.  It may be that the server-side control "class" is
the important resource, but not the conversation thread.  It is up to the
owner of URI-space to decide what are important resources.  There are lots
of funky things that people do with URIs + other information (like sessions
in http cookies) that achieve the web's scalability.  I am trying to talk
about the utility of using XML for modeling aspects of a resource, rather
than the hackneyed and unextensible ways they are currently done.  But I'm
not going to repeat myself about the advantages of XML on a w3c mailing

> > If everything related to the resource identification is
> ALWAYS munged into
> > the URI, then it is harder to extend the model for new
> interface features.
> Resource identification is always done using URIs on the Web. That's
> what makes them Uniform and Universal.

They're not Universal, only Uniform.

> > URIs have a hierarchical notion - ie.
> correlation/security/some other
> > stuff - whereas XML allows us to have a much more
> expressive content model.
> To me, that's a little bit like complaining that Intel's pointers have
> only 32 bits whereas XML is much richer. You can use *pointers to XML*
> and URIs *to XML* when you need structure.

It's more like deciding that I want a higher level language like Java that
takes care of some of the work in memory access for me.  For example, Java
has "public/private" keywords, and the VM will do some work at runtime for
me.   Again, I'm not going to go into the differences between URIs and XML.

> > IMHO, the difference between wanting to use XML's capabilities for
> > expressing information versus the URI data model is perhaps
> the core of the
> > debate.  The REST folks believe that you have to use URIs
> > URIs and HTTP) for everything necessary to access the
> resource, and others
> > think that XML is a fine extensible format for encoding
> information about
> > resource access, and it even works over other protocols.
> We all agree that XML is a fine extensible format for encoding
> information "about resource access" (e.g. authentication or even
> correlation information). Where we disagree (to be folksy) is
> that REST
> people believe that the Web already has a resource *identification*
> mechanism and inventing other ones is no more productive than
> inventing
> your own "33bit" pointer on X86 rather than using the native pointer
> understood by all the other operating system components. Using the
> standard buys economies of scale and costs nothing because
> pointers are
> just, well, pointers and there is no reason to have both standardized
> and proprietary syntaxes for them.

I think we're agreed.  Let me say back to you what I think your position is:
REST believes that URIs are complete and sufficient for universal resource
identification (gee, that acronym is uri..) and sufficient for any
representation retrieval needs, and it is crazy to invent new xml
vocabularies/whatever else to provide additional information for resource
identification and retrieval.  Owners of URI spaces must use only URIs for
resources, specifically no extra information.  People that do things with
mechanisms in addition to URIs, like HTTP cookies with session-ids, are
engaging in Very Bad Practices.

I won't go into the uniform access and a priori knowledge aspects of URI
retrieval, though it's certainly related.

Another position, is that the owner of a URI space has control over what is
considered important resources, and typically requires additional
information for retrieving the resource - like security credentials, session
ids.  This additional information could be encoded in XML.  The reason to
use XML is the extensibility and composability it offers, compared to the
capabilities of description of URI contents.  By definition, URI space
defines as "important" any resource that they create URIs for.

Received on Wednesday, 17 July 2002 18:28:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:40:57 UTC