Comments on: RESTful Data http://steve.vinoski.net/blog/2008/02/28/restful-data/ Ask forgiveness, not permission. Sun, 06 Nov 2011 14:09:37 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Weekly SOA crumbs #10 - Service Endpoint http://steve.vinoski.net/blog/2008/02/28/restful-data/comment-page-1/#comment-729 Weekly SOA crumbs #10 - Service Endpoint Mon, 10 Mar 2008 05:26:29 +0000 http://steve.vinoski.net/blog/2008/02/28/restful-data/#comment-729 [...] REST RESTful Data Idempotency of PUT, and common mistakes (via Stefan Tilkov) [...] [...] REST RESTful Data Idempotency of PUT, and common mistakes (via Stefan Tilkov) [...]

]]> By: Adam Burry http://steve.vinoski.net/blog/2008/02/28/restful-data/comment-page-1/#comment-720 Adam Burry Thu, 28 Feb 2008 18:38:46 +0000 http://steve.vinoski.net/blog/2008/02/28/restful-data/#comment-720 I liked your description of C-like structs as describing the shape of bit sequences. I also liked the idea of contrasting this with self-describing data. It reminds me of the well-known statement by Hoare, "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." Compilers are able to optimize monolithic programs because at compile time they have the complete definition of the system. Therefore, they know which registers have to be pushed before a function call, and which don't, and they know that everyone is in agreement about the "shape" of the data. However, in the distributed case, the notion of a compiler, a process with a complete view of the system, is not desirable. Or at least, not realistic. In this case, optimizing the data by obscuring its shape appears to be a premature optimization. We need flexibility there because we do not have all the information about what happens to the data next. Sections 2.4, 2.5 and 5.5 of "Structure and Interpretation of Computer Programs" by Abelson and Sussman applies here. I think even clearer than the text might be lectures 4b and 10a by the same authors found here: http://swiss.csail.mit.edu/classes/6.001/abelson-sussman-lectures/ I liked your description of C-like structs as describing the shape of bit sequences. I also liked the idea of contrasting this with self-describing data. It reminds me of the well-known statement by Hoare, “We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.”

Compilers are able to optimize monolithic programs because at compile time they have the complete definition of the system. Therefore, they know which registers have to be pushed before a function call, and which don’t, and they know that everyone is in agreement about the “shape” of the data.

However, in the distributed case, the notion of a compiler, a process with a complete view of the system, is not desirable. Or at least, not realistic. In this case, optimizing the data by obscuring its shape appears to be a premature optimization. We need flexibility there because we do not have all the information about what happens to the data next.

Sections 2.4, 2.5 and 5.5 of “Structure and Interpretation of Computer Programs” by Abelson and Sussman applies here. I think even clearer than the text might be lectures 4b and 10a by the same authors found here: http://swiss.csail.mit.edu/classes/6.001/abelson-sussman-lectures/

]]>