[REBOL] INFORMATION WORLD
From: robbo1mark::aol::com at: 8-Mar-2002 8:50
Before any of us go off re-inventing the wheel perhaps we may want ot read & consider
the REST approach and here are some useful initial links and summary.
What is REST?
REST stands for REpresentational State Transfer, a phrase coined by RoyFielding in his
dissertation attempting to describe the Web's architectural style in a rigorous enough
fashion to make the principles both comprehensible and extensible. There is also a shorter
description in an article entitled Principled Design of the Modern Web Architecture.
In particular, REST suggests that what the Web got right is having a small, global set
of verbs (HttpMethods: GET, POST, PUT, DELETE, etc) applied to a potentially infinite
set of nouns (URIs - though we're careful to keep in mind that some VerbsCanAlsoBeNouns),
because such a system allows a maximum number of otherwise uncoordinated actors to interoperate.
No matter what web server you have, and no matter what web client I have, I know if I
see a URL of yours like http://conveyor.com/RESTwiki/, that I can retrieve its contents
using HTTP methods, with no advance co-ordination needed, or that I can attempt to manipulate
its content with PUT and POST (but that it can tell me, via an HTTP response status code,
whether this is ok or not, and why).
Another way of saying this is that REST works because it keeps interface complexity from
scaling with N^2. In an infinite world of uncoordinated (i.e., independently developed)
objects that interact with one another using specialized interfaces, the interface "connection"
complexity is order N^2, because each object can have a unique interface to each other
object. An infinite world of uncoordinated objects that share a common, generic interface,
on the other hand, has only a complexity of order N, because no matter how many objects
there are, they will all be able to act on one another in predictable ways.
I'm not sure I'm comfortable asserting something as specific as O(N) vs. O(N^2). I feel
this comes down to the simpler statement that it's cheaper to extend an information space
with a new noun than a new verb. That's still fuzzy, but as far I'm willing to go right
now. More on this in NounsVersusVerbs
So how about "Complexity of implementation scales with V x N, and when neither V or N
is constrained, this approximates N^2. When V is constrained, however, then the maximum
theoretical size of the interaction space only grows linearly with N?"
[John Schlesinger]The problem with this is that you can just as easily say "when the
N is constrained, the the maximum theoretical sie of the interaction space only grows
linearly with V". You need to say why it is right to constrain V rather than N.
It seems to me that although V is constrained literally the meanings of V are not constrained.
That is, the meaning of GET, PUT and POST depends on the resource (see the examples of
HowToConvertRpcToRest). Thus, while it is easy to create clients that will interact with
the resource, creating a client that will interact with the resource in a meaningful
way is no less complex.
The REST idea of defining global methods is similar to the UNIX concept of pipelining
programs; UNIX programs all have three simple interfaces defined (STDIN, STDOUT, STDERR)
for every program, which allows any two arbitrary programs to interact. By the same analogy,
systems like SOAP or XML-RPC which tunnel a specific XML format thru HTTP-POST could
be seen as just spitting XML out of STDERR. The simplicity of REST as compared to custom
network interfaces is analogous to the simplicity of UNIX pipelines vs. writing a custom
application to achieve the same functionality. REST embraces simplicity and gains scalability
as a result; the Web is a REST system, and the generic interfaces in question are completely
described by the semantics of HTTP.
The REST hypothesis is that the semantics of HTTP constitutes a coordination language
which is is sufficiently general and complete to encompass any desired computational
communication pattern. I.e., the hypothesis is that GET / PUT / POST / etc. can provide
all coordination semantics between discretely modeled units of programs (and in case
it's not all, or there's other practical reasons for it, HTTP is sufficiently extensible
to support new methods being added). REST is comparable to message passing (provably
completely general) or function calling with parameters in its ability to express any
computational communication / coordination pattern. Obviously, there are other operations
needed to actually do the work (What does this mean???).
I take it to mean that 'other operations' are required to implement the actual funtionality
of a call such as a POST - something encapsulating application logic that knows what
to do with the bundle of name value pairs.
Why is REST important?
The Web is the most successful example of an environment that allows for interoperability
among a large number of otherwise uncoordinated actors, and inasmuch as that is a desirable
trait in a computing environment (e.g. for Web Services), the REST model provides a valuable
As RoyFielding, the coiner of REST, put it:
REST is an architecture that separates server implementation from the client's perception
of resources, scales well with large numbers of clients, enables transfer of data in
streams of unlimited size and type, supports intermediaries (proxies and gateways) as
data transformation and caching components, and concentrates the application state within
the user agent components.
The most important contrast with the REST architectural model is the Remote Procedure
Call (or RPC) model, which attempts to take the local programming model of a function
call and make it work across a network. The success of REST and the "failure" (on several
dimensions, most notably adoption across WANs and between uncoordinated organizations)
of previous attempts at RPC architectures such as DCOM, CORBA and RMI suggests that REST
has superior characteristics of scalability and mass adoption, largely because of the
low coordination costs. Cf. KindsOfCoordination.