Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search


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. cheers, Mark Dickson 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, 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 framework. 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.