"J. Andrew Rogers" <and...@jarbox.org> writes:
> On Feb 15, 2013, at 12:10 AM, John Carlson <yottz...@gmail.com> wrote:
> 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.
What you say is true, but if we're getting into custom binary formats
then there's a danger of comparing apples to oranges. The usual debate I
see is between REST and SOAP. SOAP is inherently an XML delivery
platform, otherwise there's an 'inner-platform' issue, so in this
respect the performance comparison is much closer to a RESTful XML
services than a custom binary format would be.
SOAP can be seen as an object synchronisation mechanism, where the
clients get proxy objects and pretend they replicate (some of) the state
of the server's objects. To keep the overhead down, SOAP will usually
wrap 'large' objects, ie. where a single method call can trigger a lot
of computation, and order-of-execution can matter, eg.
'update(); doA(); doB(); doC();' rather than
'updateAndDoA(); updateAndDoB(); updateAndDoC();', where the former
relies heavily on the up-to-date state persisting between method calls.
As has been mentioned on this list many times, distributed object
synchronisation is a very difficult issue, and re-implementing it for
every application that uses SOAP is a large drain on resources. This is
why I prefer REST.
REST doesn't suffer the synchronisation problem since it doesn't have
any shared state at all. Clients may decide to base future requests on
past responses, but such state is private to the client and is assumed
to be out-of-date as soon as it arrives; to make this out-of-date data
useful, a lot of the server's state will be immutable (eg. consistent
IDs, revision-based updating, etc.).
Since REST clients can't rely on chaining requests to set up their
context, each call needs to contain all of the details required to
fulfil the request. This is where the performance confusion can creep
in: shared state is replaced by in-band data. Of course, the key is that
the REST interface should be tailored to what the clients need.
Taking a SOAP API, which is suited to 'large' objects, and naively
turning it into a REST API will end up with massive requests. A SOAP API
may update a user's email address by requesting a User object for user
123, then calling "setEmail('u...@example.com')". This is low overhead
since the only transmissions were a proxy object and an email address
(and presumably a response). Transliterating this into REST would GET
example.com/user/123, dragging in a whole user record, then PUT the
whole thing (with a new address) to example.com/user/123. This is highly
inefficient and also breaks the out-of-date results assumption (any
intervening changes would be clobbered). The correct way to do this
would PUT 'u...@example.com' to example.com/user/123/email.
When implementing REST correctly, the only overhead should be a small,
constant amount due to the verbosity of authentication. In SOAP this is
only needed during the initial setup, since a pseudorandom session ID
can be used in subsequent requests. In practice, many REST
implementations use a non-RESTful session ID like this too.
Chris
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
