Jeff Bone jbone@jump.net
Thu, 17 Jan 2002 12:13:20 -0600

"S. Alexander Jacobson" wrote:

> Ok.  So is the typical CGI application consistent
> with REST philosophy?

Depends.  Are all the application objects (and collections of application objects)
themselves exposed as addressible resources?  Is the interface to those application
objects completely and consistently defined by the generic HTTP interface methods and
their associated semantics?  CGI is really a bit of a red herring --- CGI is an interface
implementation technology.  It's certainly possible to build RESTful applications using
CGI, and many CGI apps are RESTful.  It's also possible to build CGI apps that are not
RESTful;  in these cases, CGI is used to present an API that "hides" the application
objects, not exposing them as resources.  This isn't "bad," it just leads to less re-use
and more costly (on several dimensions) integration.

> e.g. Dave Winer's
> mailtothefuture.com allows one to schedule
> delivery of mail with arbitrary content to an
> arbitrary user at some point in the future.  You
> interact with this interface by sending it
> name/value pairs in the proper format.

Haven't looked at it in a while...  (checking) IMHO, REST is mostly a matter of how you
model your application domain as resources.  Many of Dave's systems --- even the "pure"
HTML / HTTP ones --- use an RPC style.  matiltothefuture, for example, has "resources"
such as


etc.  These, IMO, don't make much sense as resources --- they are, rather, procedures.
The actual domain objects of interest --- a user's queue, a particular queued message,
etc. --- do not appear to be exposed directly.  This problem is further compounded with
the various XML and XML-RPC interfaces, where not only are the resources not exposed but
the various methods are tunneled through and therefore invisible to the HTTP

Note that this doesn't mean that Dave's stuff is "bad" in any way --- I happen to think
he's managed to produce a large portion of the more interesting and useful innovation on
the Web over the last several years.  It *does* mean that anybody who wants to integrate
and reuse his stuff faces somewhat higher costs than if the application objects and
semantics were modeled in the style encouraged by i.e. URI, HTTP, etc.