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.