Relational state transfer: Difference between revisions
No edit summary |
No edit summary |
||
| Line 5: | Line 5: | ||
"Like REST's requirement to keep state accessible to all possible participating entities in a session, relational databases require that transactions be permanent, and that once committed, the changes stick." | "Like REST's requirement to keep state accessible to all possible participating entities in a session, relational databases require that transactions be permanent, and that once committed, the changes stick." | ||
"The main differences would appear to be the complexity of the arbitrary [[semi-structured data]] that is assumed to be manipulated by [[REST]], the availability of redundant sources (unlike an RDB which explicitly requires each item to be authoritatively in one place in one table), and the necessity of arbitrarily-complex resolution of which data to trust, which is assumed to be a human problem in REST but in relational databases, is more or less assumed to be up to the programs." | |||
Latest revision as of 18:50, 7 April 2004
"Relational state transfer is a term coined to parallel" (representational)REST "and emphasize what data warehouse transactions on a (quasi not strictly) relational database have in common with HTTP/REST style transactions on the web. It's reasonable to use the same acronym since the Relational is a more restricted subset of the Representational:" [1]
"Like REST's requirement to extend GET, PUT, POST, DELETE operations, relational data also is restricted to "atomic" elements arbitrarily defined (in practice, usually monetary amounts, dates/times and names). Looking at all data as constructed from one basic object type is something they have in common."
"Like REST's requirement to keep state accessible to all possible participating entities in a session, relational databases require that transactions be permanent, and that once committed, the changes stick."
"The main differences would appear to be the complexity of the arbitrary semi-structured data that is assumed to be manipulated by REST, the availability of redundant sources (unlike an RDB which explicitly requires each item to be authoritatively in one place in one table), and the necessity of arbitrarily-complex resolution of which data to trust, which is assumed to be a human problem in REST but in relational databases, is more or less assumed to be up to the programs."