REST provides a set of architectural constraints that, when applied as a whole, emphasizes scalability of component interactions, generality of interfaces, independent deployment of components, and intermediary components to reduce interaction latency, enforce security, and encapsulate legacy systems.
We treat component failures as the norm rather than the exception, optimize for huge ﬁles that are mostly appended to (perhaps concurrently) and then read (usually sequen- tially), and both extend and relax the standard ﬁle system interface to improve the overall system.
The system is tuned for a modest number of large files and presumes large streaming reads and small random reads, and many large sequential appends.
At the lowest level in git there are only
twooperations on the content store: create, read, and delete. You don't even get to choose the name of a file when it is created, all the data is written into a file (deflated with zlib) where the filename is the sha1 hash of the contents.
Performance, either defined as speed or as scalibility, is achieved in each system because of the chosen constraints.
What are your constraints? And what are they buying you?
Posted by Joe on 2007-03-19
Posted by Karl Dubost, W3C on 2007-03-19
Posted by Paul Morriss on 2007-03-19