On Feb 15, 2013, at 12:10 AM, John Carlson <yottz...@gmail.com> wrote: > > I can't say anything about REST in general being slow. I would like to see > better support for adding multiple objects to a collection in HTTP REST, > perhap by using MIME.
REST is not a highly efficient protocol by any means but most of the slowness people attribute to REST has more to do with what people transport inside a REST operation than REST itself. REST is often below the performance noise floor if it is well-used despite its inefficiencies. REST is commonly used to transport XML or JSON or similar. Parsing JSON or XML encoding structures is quite slow because they are intrinsically inefficient as wire encoding formats. Compared to common efficient encodings, the difference in cost exceeds an order of magnitude in practice. For example, I currently have a system that parses, processes, and indexes complex geodetic polygons at sustained rates of many gigabytes per second (for real-time petabyte-scale sensing models of the Earth). The largest total consumer of CPU time by far is not computational geometry, network processing, or anything like that but parsing JSON source formats -- and we've invested a lot of time in highly optimizing JSON parsing. The internal binary format used by the same system disappears below the noise floor. As a practical matter, most people that use REST use JSON or XML and most people that don't use JSON and XML also don't use REST for related reasons. But it is not fair to blame REST for what is primarily an issue with JSON and XML even though they are often seen together. REST is not efficient but it usually pretty low on the long list of things that are slowing down an application. _______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
