[
Lists Home |
Date Index |
Thread Index
]
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
|
