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

Jeff Bone jbone@jump.net
Wed, 08 Aug 2001 17:08:25 -0500


Mike Dierken wrote:

>
>
> > > Now, doubtless, there's a lot of servlet and Web
> > >development knowledge out there;  but most enterprise
> developers, data
> > >modellers, etc. I know still live in UML- and OOP-land, and this
> is as
> > >significant a change as the procedural->object transition of a
> decade
> > >or so ago.
> >
> > Agreed.
> >
> How does the UML/Object-model view clash with REST?

Certainly you can do (constrained) classical OOAD and end up with
REST, but you've got to constrain the interfaces of all your objects
to the existing HTTP methods:  GET, PUT, POST, etc.  It's about
generic interfaces on lots of different domain objects and their
representations, rather than a few domain-specific objects with
unique interfaces.  The process is about force-fitting your
application domain into a small but powerful set of generic
abstractions on a shared space, like Linda or UNIX pipe programming
or Plan 9 namespace construction or device driver construction,
rather than about modelling the application domain independent of the
specifics of your integration framework / architecture...

At least, that's my current understanding after days of marinading in
the REST POV... ;-)

Thinking about it, it seems to me that there's always been a bit of a
dichotomy out there in design-space;  system programming has always
felt a lot more like REST, i.e. with an emphasis on making your
domain fit into generic interfaces, while app programming has been
much more about modelling the application domain precisely then
worrying about integration issues.  In some sense, one REST mantra
could be "if app programmers simply thought like systems programmers,
the world would be a better place."  And, now that I think about it,
I've always believed that anyway...  ;-)

jb