REST: everything old is new again?

Bill Hofmann wdhofmann@home.com
Fri, 24 Aug 2001 22:08:27 -0700


> One funny thing about REST is the way it tends to get the blood
up, as
> a topic of discussion.

It's natural that proponents of a new way of thinking about
design should aggressively state their case, and the old guard
should feel threatened.  At one of the early SOAP BOFs at
Netscape, it kinda felt like that, but with Don Box and some of
the other SOAPers being the threatening ones.


The power of OO, to me, is a way of *codifying* best practices
for building code: Booch and cohorts didn't invent encapsulation
or other good things, they provided a *new way* of thinking that
made doing the right thing easier.

In the same way, though I'm still resisting being absorbed, REST
is interesting.  What it seems to be saying is (taking an OO
tack) attributes are cheap, and methods are expensive, so use
lots of attributes and getters and setters.  Or in the REST way,
resources are cheap and methods are expensive.  So given a set of
*things* you want to do, make them URIs, and use HTTP methods to
effect the implied functionality.

Am I getting this right?

So given an class with certain methods and certain attributes,
one can represent the methods and attributes as a set of SOAP or
other RPC methods.  Or one can represent the methods and
attributes as a series of URIs and a small set of verbs
(GET/PUT/DELETE/POST).

I'm not sure I'm seeing a difference that makes a difference,
from a *design* point of view, and even from an implementation
point of view.  I'm troubled by the implied coupling to HTTP, but
maybe that's just my unwillingness to commit :-)

What bothered me before and still bothers me is the implication
that by transforming to REST, all issues of interface complexity
go away.  I don't buy that.  Indeed, knowing how to tell someone
how to call an RPC call is difficult.  However, doing a GET or
POST on a URI is just as difficult: how do I form the URI?  It
requires, in both cases, a definition of the preconditions,
operation (name and arguments or URL and verb), and
postconditions.

Now I don't agree with all of the statements at
http://internet.conveyor.com/RESTwiki/moin.cgi/KindsOfCoordinatio
n, but this seems to me to be a valuable train of thought.

-Bill