On Tuesday 25 April 2006 11:31 pm, Stewart Stremler wrote: > begin quoting Tracy R Reed as of Tue, Apr 25, 2006 at 10:10:29PM -0700: > > Yet another interesting concept that has been around for a number of > > years that I am only now learning about. The concept of the URL really > > is something powerful. Add a few universal verbs and you may just have > > something.
I have been following the REST Discussion list for some months now. http://groups.yahoo.com/group/rest-discuss/ Here is what I have digested from that list. In practice REST is essentially a style for using http effectively to build scalable applications. REST and HTTP say that the requests sent to servers include the following things: A verb. A resource. A collection of headers. Those things are the tools at our disposal for understanding the 'context' in which a server carries out processing. There is a case for viewing those things as: A subject. A verb. An object. The http verbs that go a long way are GET get the resource POST create a new resource PUT edit the resource DELETE remove the resource HEAD brief overview of the resource And this from Roy Fielding: Hint: A RESTful system progresses from one steady-state to the next, and each such steady-state is both a potential start-state and a potential end-state. I.e., a RESTful system is an unknown number of components obeying a simple set of rules such that they are always either at REST or transitioning from one RESTful state to another RESTful state. Each state can be completely understood by the representation(s) it contains and the set of transitions that it provides, with the transitions limited to a uniform set of actions to be understandable. The system may be a complex state diagram, but each user agent is only able to see one state at a time (the current steady-state) and thus each state is simple and can be analyzed independently. A user, OTOH, is able to create their own transitions at any time (e.g., enter a URL, select a bookmark, open an editor, etc.). Commented by Ben Carlyle: What happens inside the server usually has nothing to do with REST. It can access whatever data it chooses to return the resource state. You can think of the client as a world of hideously interconnected and coupled components, such as a desktop application suite. You can think of the server as a separate world of hideously interconnected and coupled components, such a database and application server. REST doesn't constrain either one to behave in a particular way internally. REST is a formula for ensuring that what happens between these complex worlds doesn't cause them to be coupled to each other as well as to themselves. (messy, coupled client) <---REST---> (messy, coupled server) and others: The important point of REST is decoupling the client from the server thus one gets benefits of scaling and cacheability. Issues that often come up are sessions (not RESTful) and cookies (also not RESTful) with observations like: There are reasons to prefer putting info in URIs instead of cookies: 1. URIs can be bookmarked. Cookies can't. 2. URIs can be linked to. Cookies can't. 3. URIs can be e-mailed. Cookies can't. 4. URIs can be copied and pasted into a different browser. Cookies can't. Now finally for an example of how one uses AJAX on the client side with REST to build a responsive application see: http://www.onlamp.com/pub/a/python/2006/02/23/using-rest-with-ajax.html We will see a lot more AJAX + REST as the web evolves. > This would be a concept from a guy who can't spell, hm? > > /me reads > > Y'know, I don't see the allure of "universal verbs". > > I tried to build a 'universal verb' shell in the early nineties. It > failed miserably... there's no good way to resolve ambiguity. You end > up encoding a ton of implicit knowledge in how you do things, rather > than explicitly indicating this. You say you failed. The web appears to some to have been successful. Whose advice should we follow? BobLQ -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
