Comparing the "Economics" of REST and RPC

Jeff Bone jbone@jump.net
Sun, 12 Aug 2001 04:30:27 -0500


As I've noodled through this REST / RPC argument for the last few
weeks, the quality that seems most to favor REST appears to be a kind
of economic one.  Now, this is pretty stream of consciousness, but
here's an attempt to sort of quantify the matter.

Imagine a system of components, each of which needs to interact with
the others to accomplish some desired functionality.  In the RPC
case, let's say it's a system of N objects, each of which has some
number M methods.  One measure of the "cost" of interface complexity
* in this system would be some value proportional to the square of
the sum of the number of methods exposed by each object:  (M[1] +
M[2] + ... M[n])^2.  It's order N^2.

In the REST case, there is probably some inflation of the number of
objects --- resources --- needed to represent the system;  let's say
it's N*I resources instead of N objects.  Each of the various
resources has an identical generic interface;  let's say each
resources supports just 3 methods, GET / POST / PUT.  The overall
complexity cost of this system is then proportional to 3NI.

Now, that's not the whole story, of course.  There's additional
complexity in the REST case due to the "largeness" of the
representations exchanged;  but there's ample evidence to support a
"power of large values" conjecture which supposes that this
complexity is somewhat offset by other gains.  APL gains tremendous
expressivity by having operations that act on large values as a
whole;  similarly for LISP and the functional languages;  even Perl
gains expressive power and performance by its high-level treatment of
and operation on whole lines / streams / files in single operations.
Given the tradeoff of power for complexity in dealing with large
values --- representations, documents --- in REST, I'd speculate that
overall increase in complexity is some small integer factor, C.  So
the overall complexity cost of a REST system is then something like
3NIC.

In general, the difference in interface complexity costs for the two
systems is something like order N for REST vs. order N^2 for RPC.
For very small systems, REST may be slightly more complex than the
RPC system.  The difference grows to favor REST exponentially with
the number of components there are in the system.  As N grows, the
additional complexity stemming from the largeness of representations
in REST is quickly overcome by the exponential interface &
interaction complexity in the RPC model;  if 3IC < N, then the REST
system is in some sense less costly, and becomes exponentially less
costly vs. the equivalent RPC system as N grows.

Now, I dunno if I totally believe this, but it seems a reasonable
starting point for analyzing and comparing the complexity of REST and
RPC systems...

Feedback?

jb

* Side note:  I've always considered the cost of a programming
interface in terms of its "surface area" --- i.e., the total number
of method interfaces I've got to learn --- and its "semantic volume"
--- i.e., the total number of combinations of method calls possible
for some number of method calls, with resulting state transitions.
In some sense the "robustness" of any given system of interfaces is
the proportion of valid combinations of methods resulting in sane
"states" in the semantic volume vs. the overall semantic volume.)

PS - one other thought.  I've come to the conclusion through a bunch
of little experiments that designing for REST requires an abstraction
skill and mindset that is alien to those who've come to think in an
OODA kind of mode.  Decomposing a problem domain into a set of
resource representations with generic interfaces is *not* the same as
decomposing the same domain into a set of objects and type-specific
operations on those objects;  it's harder in many respects.  I know I
posted it [1] before, but it's a particularly great case study of the
kind of thing we're talking about --- Plan 9 is a very RESTlike
system:  consider the design of the Berkeley sockets interface with
the way that networks are abstractly represented in Plan 9.  The Plan
9 design is in no way immediately obvious, except in hindsight;  but
the benefits seem, to me at least, hard to argue with.  Still,
there's definitely an impedance mismatch between the OODA school of
thought and REST.

[1] http://www.cs.bell-labs.com/sys/doc/net/net.html