Paul Prescod on REST architecture

["Drummond Reed" <drummond.reed@cordance.net>]

XDI TC Members & Observers:

As we start getting deeper into discussions about XDI as a protocol, I want
to pass on a reference to this 2002 article on WebservicesXML.com about REST
architecture by Paul Prescod:

	http://webservices.xml.com/pub/a/ws/2002/02/20/rest.html?page=1

In particular, note what he says on page 2 about the "few verbs, many nouns"
philosophy of REST (excerpted below for quick reference). It certainly
suggests that we should choose our verbs very carefully.

=Drummond 

***BEGIN EXCERPT***

Every method that can be invoked on a resource or service is a possible
connector between the client and the service. If every service has a hundred
different methods then your connections become very complex -- essentially
point-to-point integrations rather than reusable patterns.

There are various systems in the computing world that have proven the power
of having just a few methods rather than many. For instance, every true Unix
hacker knows that the command line is incredibly powerful because it is
possible to pipe data from one process to another using the redirection
"methods", ">", ">>", "<". The other Unix command line tools act as
standardized filters and transformers connected by these methods.

Similarly, if you think of a SQL table as a resource, the methods SQL makes
available are only SELECT, UPDATE, INSERT and DELETE. The rest of SQL is a
set of transformers and filters that allow you to combine these methods into
services. .NET My Services has Query, Insert, Replace, Update and Delete. As
I showed in the last article, UDDI has get_*, delete_* and save_*. This
pattern is ubiquitous: a small number of methods applied to diverse kinds of
data.

HTTP has GET, PUT, POST, and DELETE. Anything that can be done with SOAP RPC
or any other RPC can be done with those four methods. In fact, it is
precisely because HTTP has few methods that HTTP clients and servers can
grow and be extended independently without confusing each other. Rather than
invent new methods they find ways to represent new concepts in data
structures (increasingly XML data structures) and headers.

***END EXCERPT***