RESTful Web services and DAL

[Doug Tody]

On Tue, 13 Mar 2007, Doug Tody wrote:
> A key characteristic of RESTful services appears to be an attempt to
> represent resources and state as "[file-like]" references, i.e., URLs in
> the case of the Web.  In Unix file system terms, /proc is an analogous
> mechanism.

> This would seem to work well for state, but a strict path-oriented
> approach (as in http://blabla.edu/cutout/301/22/bombayduck) does not
> work well for service operations.  Operations are hard to define [without]
> some sort of parameter or argument mechanism.

I may be enlightening to look more explicitly at the /proc analogy.  If on
my Linux system I look at process pid=21 I get:

     % ls /proc/21
     attr  cmdline  environ  fd        maps  mounts  stat   status  wchan
     auxv  cwd      exe      loginuid  mem   root    statm  task

which tells me about all sorts of interesting information I can
retrieve, without my ever having to read about kernel process
structures.  Then I can do

     % cat /proc/21/status
     Name:   khubd
     State:  S (sleeping)
     SleepAVG:       98%
     Tgid:   21
     Pid:    21
     PPid:   1
     TracerPid:      0
     Uid:    0       0       0       0
     Gid:    0       0       0       0
     FDSize: 32
     Groups:
     Threads:        1
     SigPnd: 0000000000000000
     ShdPnd: 0000000000000000
     SigBlk: fffffffffffffeff
     SigIgn: 0000000000000000
     SigCgt: 0000000000004100
     CapInh: 0000000000000000
     CapPrm: 00000000ffffffff
     CapEff: 00000000fffffeff

which returns a simple block text containing parameters describing the
process, i.e., a set of keyword-value pairs (easily machine readable
despite not using XML).

This would seem to be a good illustration in more familiar
terms of what is intended by the REST approach where we merely
use the Web instead of a Unix file system.  File URLs are used to
address resources and state information, in this case the state of a
long-running process.  The mechanism is simple but powerful; standard
protocols and tools (ls, cat) can be used to access this information.
In get analogous Web case we could use things like wget or curl.

Note however, that while this mechanism can be used to "get" state,
and given sufficient permission we might be able to "put" bytes to a
file interfaced via /proc or /dev, we don't use these mechanisms to
*run* a process.

To run a process (change the system state) we execute a command,
using a shell or the exec system call, or we invoke an operation on a
kernel service or daemon, and so forth.  This may result in new state
information showing up in /proc.  For example "/usr/bin/cmd <args>".

The analogous "execute" operation on the Web is GET or POST, both of
which can execute a command with parameters.  In this case the Web
goes one step further than Unix, as *merely reading* an executable
file is allowed to transparently execute the file.  GET defines
a syntax which allows the command arguments to be folded into the
command reference as one long string, the URL.  A clever Unix file
system driver could be written to do this same thing.  POST is a more
explicit command invocation, which separates the command arguments
from the command reference.

In short, REST is basically just the Unix "file" concept mapped
onto the Web, with GET serving a clever dual role.  As a result,
standard protocols and tools can be used to do useful things.  SOAP is
(primarily) an RPC protocol, defining a standard encoding to invoke
a remote method on a object.

 	- Doug