Andrew,
J. Andrew Rogers wrote:
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.
I agree with your conclusions, but I have to say that statements like
this drive me absolutely crazy - for several reasons - the main one
being that REST is not a protocol - it's an architectural style / a
design pattern for designing APIs - primarily APIs that are carried over
HTTP (which IS a protocol). And the contrast is usually made to W3C
style web services - which is a very different way of defining and
carrying transactions over HTTP (mostly involving lots of XML and lots
of extraneous headers that are usually left empty).
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.
Now, if you want to say encoding transactions as XML or JSON, and
executing them over HTTP, is slow - that's probably an accurate statement
over HTTP, is slow - that might or might not be an accurate statement -
depending on what you're comparing to. Wrap the same transaction in
SOAP headers (per W3C web service specifications), and run it over HTTP,
and you'll slow things down a lot. Push the transaction over a raw TCP
socket connection, and it will be marginally faster.
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.
And now we're back to matters that really make a difference, but that
are orthogonal to REST. You can push things other than XML and JSON
over HTTP, and you can do it in a RESTful manner or not. And you can
push things across the net using other kinds of protocols.
For the application that you describe - streaming huge datasets -
RESTful interfaces, and HTTP, are probably not particularly effective.
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.
I'm not sure I completely agree with you here. There are an awful lot
of RESTful interfaces to things like imagery and map databases. What
makes them restful is how data is addressed (by URL), and the use of
HTTP operations to GET/PUT/DELETE data, but the actual data formats are
content specific (audio formats, video formats, shape files, etc.)
Miles Fidelman
--
In theory, there is no difference between theory and practice.
In practice, there is. .... Yogi Berra
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
