REST: everything old is new again?

Mark Baker
Sat, 25 Aug 2001 01:54:39 -0400 (EDT)

> 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.

I didn't get that feeling.  I suppose the fact that Don was
calling in, muzzled some of that threatening tone. 8-)

> 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?

Almost.  To stick with your "OO tack", I'd suggest that what
it says is "make lots of objects" (things with identity), but then
have one GET method for returning serialized representations of
its state, one PUT method for setting that state explicitly with
a serialized representation, and one POST method for changing its
state relative to its current state by augmenting/annotating/adding
a serialized representation to itself (the container model, basically).

> 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?

You don't, in most cases.  You're provided it.  It's opaque.

>  It
> requires, in both cases, a definition of the preconditions,
> operation (name and arguments or URL and verb), and
> postconditions.

What do you mean by "operation"?

As for conditions, HTTP takes care of some of the transfer pre/post
ones, e.g. GET's postcondition is that state(post GET)=state(pre GET).