REST, RPC, mountains, molehills, and a retraction (sort of)

Clay Shirky
Wed, 8 Aug 2001 17:22:43 -0400 (EDT)

> Over the course of the FoRKBreak, I've had several good discussions
> with various folks about this whole REST vs. RPC thing, in particular
> a great and detailed exchange with Mark Baker.  (Thanks Mark!)

I had the same experience (thanks mark). IMO, he (and to some extent
aaron) were leading with the weakest arguments about http methods,
when the much stronger arguments are the weaknesses of RPC.

> Let's look at these.  The caching argument (1) is, IMO, the weakest of
> the arguments.  The caching architecture of the Web isn't always a
> good thing, or the right thing;  the (in practice) loose semantics of
> POST has been a good way of dealing with this.

Furthermore, the (in practice) loose semantics of POST means that the
existing developer community will have to learn tighter semantics to
use REST -- it isn't merely an extension of existing practice.

> (2)  is not a
> particularly good argument against RPC, either;  first, there are many
> dimensions of scaling, and which dimensions are most important is an
> application-specific consideration.  Not everybody is building Hotmail
> or HotOrNot;

no no no no no. we only know in retrospect what it means to build a
hotmail or hotornot. you should use architectures that scale, even if
you are building an integration pipeline between two corporate apps at
first. otherwise, you end up having to re-build if it catches on.

> necessarily the right approach to the other.  (3) is probably the most
> compelling but under-elaborated argument;  a service offered in a REST
> style will inherently be more "consumable" than some complex API, and
> will have a lower learning curve for the consumer and lower support
> overhead for the producer.

I'd add 

(4). XML is *too* extensible, leading to the possibility that two
   implementations will both have methods called "convertTemperature",
   but will expect different ways of identifying F or C, and will
   accept or reject floating point numbers, etc.

The risk to web services from both bit rot and subtler forms of
breakage over time are *extreme*.

> Obviously, the differences between "good REST design" and "bad RPC
> design" can be quite subtle.

Here's what I think it is, after talking to Steve Burbeck at IBM.

RPC is an attempt to apply single-machine programming conventions to a
network. Too often, this ends up being C-style function calls, meaning
that the caller has to know (or assume) lots about the internals of
the remote service. 

The glory of the web is that since you can't write your own methods,
you use the existing small number of methods on a large (huge, vast,
exploding) number of nouns. REST is a way of describing what you
expect of the remote resoruce, without having to describe the

So what does a temperature converter via REST look like?

Will get to the rest of this later. This is a fantastic post.