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

Mike Dierken mike@DataChannel.com
Wed, 8 Aug 2001 14:56:58 -0700


This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C12055.0BA36090
Content-Type: text/plain;
	charset="iso-8859-1"

Good post. It definitely had good side-effects.


> Furthermore, as a design style, it's one that
> when pushed to its extreme *can* have significant costs for
> developers;  rather than developing object models using traditional
> OOP design techniques and then automagically exporting them to the
> Web, developers must decompose their objects in a different fashion
> and, perhaps, even go to a phenomenal amount of trouble to explicitly
> provide the marshalling / unmarshalling / parsing of things to and
> from the request and response streams.  StockTicker is much more work
> to build as a servlet, say, than as a Web-naive class that is
> automagically published to the Web via some RPC framework...
> 
I wrote a framework for doing web-native (not web-naive) servlets.
Its at http://xml.apache.org/xang/

It tries to provide the framework that bridges between URI's and object
lookup and also
make it easy to write resource specific implementations of GET/POST/etc. (as
well as arbitrary methods, pluggable method invokation protocols, pluggable
authentication, etc.).

Still, programmers tend to want to do method=getMyGoat rather than lookup
the 'MyGoat' resource handler and invoke get().
It just seems to be too convenient to use the 'command pattern' and make
your objects represent a function. Even though building 'resource type'
objects fits very well into the OOP paradigm.

mike

------_=_NextPart_001_01C12055.0BA36090
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">



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



Good post. It definitely had good = side-effects.


> Furthermore, as a design style, it's one = that
> when pushed to its extreme *can* have = significant costs for
> developers;  rather than developing object = models using traditional
> OOP design techniques and then automagically = exporting them to the
> Web, developers must decompose their objects in = a different fashion
> and, perhaps, even go to a phenomenal amount of = trouble to explicitly
> provide the marshalling / unmarshalling / = parsing of things to and
> from the request and response streams.  = StockTicker is much more work
> to build as a servlet, say, than as a Web-naive = class that is
> automagically published to the Web via some RPC = framework...
>
I wrote a framework for doing web-native (not = web-naive) servlets.
Its at http://xml.apache.org/xang/

It tries to provide the framework that bridges = between URI's and object lookup and also
make it easy to write resource specific = implementations of GET/POST/etc. (as well as arbitrary methods, = pluggable method invokation protocols, pluggable authentication, = etc.).

Still, programmers tend to want to do = method=3DgetMyGoat rather than lookup the 'MyGoat' resource handler and = invoke get().

It just seems to be too convenient to use the = 'command pattern' and make your objects represent a function. Even = though building 'resource type' objects fits very well into the OOP = paradigm.

mike

------_=_NextPart_001_01C12055.0BA36090--