Comparing the "Economics" of REST and RPC

Roy T. Fielding fielding@ebuilt.com
Wed, 15 Aug 2001 22:27:51 -0700


> > The difference in interface complexity is an interesting comparison.
> 
> I think it's really at the core of what's fundamentally and practically
> significant about your observations.  Many of the other things seem to me to
> be trees;  the issues which drive cost, integration opportunity, and
> complexity --- and hence adoption --- seem to me to be define the forest.

That's a possibility, but if I were to approach it that way in a dissertation
it would require a different type of validation.  My issue was to find
where the trees are standing, not to define which one was most important.

> Even a partial understanding of how architectural styles and their natural
> programming models impact these things in complex systems would be a
> tremendously significant result in computer science.

Yep.

> > You missed one variable, though -- time.  REST has problems with broken
> > resource identifiers, but that is comparable to lost objects.
> 
> So:  do you think that's a fundamental problem in REST in the abstract, or an
> artifact of the current instantiation?  That is, do you think there's any
> *possible* way to deal with this problem that doesn't introduce brittleness
> and non-scalability?

I think it depends on the source of the brittleness.  I don't think it is
a factor of REST because I haven't found an alternative which was just as
expressive but less brittle.  I think it is simply the balance between
letting people define their own names (resulting in lower entry barriers
and better social effects) and yet expecting those names to be valid
in a much larger context than might be envisioned at the time of naming.

> > Typical
> > RPC-like architectures also have to deal with the fragile base class
> > and interface versioning problems -- issues that are hidden behind the
> > REST interface because the client doesn't have to deal with strong typing.
> 
> Woudn't you say that the various XML initiatives introduce some flavor of
> typing, albeit typing "under the hood" where the interfaces are all
> essentially foo(ANY)?

Most of them do.  It is much like the theory of SGML DTDs -- that you have
some external grammar that the format must obey, and the system is supposed
to fail hard if anything is out of place.  Well, people don't like that in
a distributed system -- it isn't easy to go find the author of your favorite
resource and whack them upside the head until they correctly format the
file according to some well-defined grammar.  Best effort is preferred in
almost all cases (the exceptions being where safety is a concern).  But
that doesn't mean the DTD itself is useless, since it can still be used
to guide an author or verify test results.

XML is a fine format for resource representation.  I just think it sucks
for control messages, where strong typing/DTD behavior is not desirable
and a simple, easy-to-parse syntax is far more useful.

....Roy