[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Re: Why REST was Re: URIs are simply names

urns vs. urls
Gary Stephenson wrote:
> In particular the notion of the actual physical representation being used to
> store the actual resource/data being a totally inaccessible implementation
> detail - with only "possible representations" of the data being accessible
> seems exactly the same in both fields. 

True! And also to some extent in object oriented theory. The main idea
in all three is the same: a clear boundary between implementation and
interface, as well as customer and producer.

> ... Note also that Date places some
> fairly heavy-duty restrictions on what "representations" actually are, and
> how they must work in order for them to integrated properly into the DBMS. -
> roughly that each representation consist of a named set of mutally
> orthogonal scalar-valued properties (I think <g>).  Have similar concepts
> also evolved in best-practice REST implementations?.  Should they?  Could
> they?

REST is mostly about networking and it basically tries to be agnostic to
the actual data being transmitted. After all, how could you express very
strict constraints about PDFs or HTML documents? But maybe when applied
in particular to process-oriented XML we could derive some rules.
Especially around RDF, which has a lot in common with databases.

> How "truthful" is the analogy of considering the entire world of
> URI-addressable HTTP resources as one gigantic database,  the HTTP protocol
> itself as the DBMS, and URIs as the key-values.  Is the analogy close enough
> to warrant further scrutiny of the best practices in the DBMS world?  

To some extent, but remember that many of the problems we are trying to
solve are quite different. Relational databases tend to trust their
clients. If the client says: "please lock these records" then the
database locks the records and if the client goes away it is screwed.
You can't do that on the public internet. That's why I'm so skeptical of
products that claim to make it really easy to just wrap an existing
database or object or network access.

> I also suspect that a fuller understanding than my own of exactly why Date
> is so adamantly against ObjectIDs (aka references/pointers) appearing as
> part of the logical data model would provide useful insights on some of the
> issues surrounding URIs vs URLs/URNs, entities vs. resources, and the
> further development of REST-ful best practices.

Perhaps. But practically speaking I don't think a massively distributed
system can get away without pointers/addresses. You can't expect to just
find things based on their properties as you would in a relational
database. Eventually you need to "address" some other machine to ask it
to get the information for you. One distributed computing model that
gets away without addresses is the Linda/tuple spaces model. But I don't
know whether that scales and I can't imagine how it would.

 Paul Prescod


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.