Re: Genericity, strong typing, SOAP-RPC, GRASP, and defining the Web

Miles Sabin wrote:

> How does the receiver "party with anybody" other than by being able to
> process all ten message variants that it might receive? And isn't that
> just moving complexity from one place to another? Why here rather than
> there?

Consider a "general" type --- say, text streams ala UNIX --- vs. a
"specific" type, say "class AddressBook."  Now an address book can
certainly be represented as a structured text stream.  As such, many
interesting things can be done with it even by programs which don't
understand class AddressBook:  the lines can be counted, it can be
searched for occurrances of "Sabin," etc.  Representing an address book as
a text stream doesn't prevent code that understands the address book
structure from using it as such, but representing it as an instance of
class AddressBook may prevent other code from using it for any purpose.

Graph structures may play the same role for the Web that text streams play
in the above example.  None of us --- I hope --- argue about the
desirability of interacting with networked resources via exchanging
XML-structured data.  The question is "what does that graph structure
mean?"  REST --- and perhaps the Web itself --- has as its fundamental
paradigm exchanging representations of resource state rather than
encapsulating them behind type-specific interfaces.  If the XML being
exchanged does *not* represent the state of the resource, then there are
perhaps very generic applications of interest that cannot be usefully
performed on said XML regardless of its type.  This is how SOAP-RPC breaks
the Web:  it subverts the very notion that what's being transferred is a
state representation rather than a set of parameters to some arbitrary
operation.

> There could be lots of answers to that last question, some of them
> technical, some of them political and economic. But "because it
> reduces overall complexity" isn't likely to be one of them.

Again, we're talking about *compositional* complexity, here --- though
there may well be more general complexity implications -wrt-
implementation complexity measured in various ways, etc.  The complexity
we're talking about is the number of interfaces that need to be understood
and supported in order to operate on any resource type.  Clearly,
supporting 10 different type interfaces in e.g. a caching proxy --- i.e.,
let's say there are 10 ways to "get" a meaningful and complete
representation of resource state for 10 resources --- is more complex than
supporting 1.  Discouraging / disallowing that kind of type-specific
interface and encapsulation obviously and incontrovertibly reduces that
kind of "overall" complexity.

jb

Received on Tuesday, 26 March 2002 21:25:54 UTC