Re: REST & types

[Gavin Thomas Nicol <gtn@rbii.com>]

On Thursday 28 February 2002 10:56 pm, Mark Baker wrote:
> POST it a representation of some food, and it gets fed.
> POST it a representation of a hand, and it gets petted.
> (logically, of course 8-)

This is the point though... to a large degree all that's really 
happening is  decomposition/tunelling of higher-level communication 
patterns on a lower-level substrate... there are advantages and 
disadvantages to this.

> Yup.  But everything that can be done by distributed computing can
> be done by distributed hypermedia.  It's complete.

Sure... and all computation can accomplished using SK combinators.

One thing I've often done in developing object interfaces is to 
essentially make everything a "bag" of properties (get/set/remove), 
allowing arbitrary extension of "types" at runtime (in JAVA you can do 
it through a custom classloader if you want). This can be very 
beneficial (slot-based programming is similar BTW).

Anyone who's done this (especially if they're an old lisp hacker ;-)) 
will eventually question the need for objects/interfaces in the first 
place... after all, the common substrate is all you need. The answer, 
as it is for the applicability of anything, is "it depends".

Reductionism is fine (big fan of reductionism and minimalism in 
general), but you also need the higher level of organization, and 
labels to apply to them. Once you start operating at that level, the 
underlying components become less relevant... that's the whole point 
of abstraction. Once you start modelling higher-level applications 
(working at a higher level of abstraction), will the choice of REST be 
truly significant? Will the choice of REST using HTTP vs REST using 
<whatever> be significant?