Re: Re: Why REST was Re: URIs are simply names
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
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format