Read all about it over here: http://internet.conveyor.com/RESTwiki/moin.cgi http://www.xml.com/pub/a/2002/02/06/rest.html http://internet.conveyor.com/RESTwiki/moin.cgi/RestFaq ---- This is what Roy Fielding, REST's coiner, says The World Wide Web architecture has evolved into a novel architectural style that I call "representational state transfer." Using elements of the client/server, pipe-and-filter, and distributed objects paradigms, this style optimizes the network transfer of representations of a resource. A Web-based application can be viewed as a dynamic graph of state representations (pages) and the potential transitions (links) between states. The result 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. ---- FWIW, this wiki is being adjusted according to the REST philosophy. Each page in this wiki now has one "official" way of being identified, i.e. this one is: http://mini.net/tcl/3513 No ".html" at the end, preferably. Two other valuable access paths are "tolerated" (both redirect to the above one): http://wiki.tcl.tk/3513 <== preferred for public use, e.g. comp.lang.tcl http://purl.org/tcl/wiki/3513 <== fallback, in case anything breaks ''Other ways to reach this wiki are obsolete, including everything with "cgi-bin" in it.'' -jcw [KBK] (21 October 2002) - Please tell me that accessing pages by full title, ''e.g.,'' http://wiki.tcl.tk/REpresentational%20State%20Transfer%2c%20REST is still acceptable? ''Ah, yes... of course - numeric access is indexed, all the rest triggers a search, and remains fully supported - thanks for pointing this out. [jcw]'' ---- [SC] As I understand it, REST emphasises Resources which can be accessed via a URI and suggests using the http GET, PUT, POST and DELETE methods as per their original specs. Accordingly it should be possible to GET the contents of a page (a resource) either as HTML or Wiki Source or whatever other formats the wiki is able to deliver. Editing a page should be possible through a POST (as now) or PUT request, new pages should be added using PUT. Now, the current browser based interface uses HTML forms and POST because that's how you can provide an easy browser based editor. If the GET of Wiki markup and PUT/POST to upload edits were implemented one could imagine a local tcl app which could download pages from here, edit them and send them back -- sort of tkchat like. This wouldn't remove anything from the current interface, just add the possibility of new kinds of apps. How about the following urls with different HTTP Accept headers: * GET http://purl.org/tcl/wiki/3513 Accept: text/html delivers html * GET http://purl.org/tcl/wiki/3513 Accept: text/wml delivers wiki ml source * PUT http://purl.org/tcl/wiki/3513 uploads a new version * POST http://purl.org/tcl/wiki/3513 uploads diffs from the old version (on edit) '''[DGP]''' Why are you proposing different URIs for different formats of the same resource? Isn't this properly done in HTTP 1.1 by setting the Accept: header? [SC] of course, I'd forgotten about accept. (I've modified the above accordingly, it originally had different extensions for different types). Now the Accept header dictates the type of data returned. There is a conflict with the existing implementation where POST to a URI uploads a new version rather than diffs, this could probably be managed via additional form fields though. [JE] IMO, using different URIs for different formats is acceptable, and even preferable in many cases. HTTP Content negotiation (the Accept: header) is badly flawed; I liked the original scheme better. http://wiki.tcl.tk/3513.wml would always return the editable version, http://wiki.tcl.tk/3513.html would always return the HTML-formatted output. Content negotiation is a good idea for the case where there's no extension though. (PS I'd ''love'' to see the GET *.wml / PUT interface implemented. Then I could whip up a 4-line Tcl client to download/upload wiki pages and use a decent text editor instead of this stupid textarea :-) ---- Pertinent references: * short introduction [http://www.sys-con.com/xml/article.cfm?id=454] * overview [http://www.prescod.net/rest/rest_vs_soap_overview] * design of REST: mistakes [http://www.prescod.net/rest/mistakes] * design of REST: .NET [http://www.prescod.net/rest/dotnet] * design of REST: [RPC] [http://www.prescod.net/rest/rpc_for_get.html] * design of REST: ... extreme ... [http://www.prescod.net/rest/Steps_to_extreme.html] * security ... [http://www.prescod.net/rest/security.html] * security ... [http://www.xml.com/pub/a/2002/02/20/rest.html] * REST vs. SOAP [http://www.intertwingly.net/stories/2002/07/20/restSoap.html]