Wikis fit very closely with the RestArchitecturalStyle. Each Wiki page is a separate resource whose state is returned as a result of a GET invocation with a browser. Not that REST requires this, but all Wikis distinguish between different representations of state for the purposes of setting vs. viewing Wiki pages. This is also consistent with REST.    (KT)

The main source of incompatibility is that no Wikis (AFAIK) support PUT, due entirely to the lack of support in today's browsers. It would also obviate the need for the "Edit Text" link on Wikis, since all content is editable on the client (though perhaps an alternate representation of the page would be needed to edit it); the hard part is trying to PUT it back to the server. PUT would be a more appropriate method to use than POST, because PUT exists for the purpose of setting state explicitly (as is done to a Wiki page when edited).    (KU)

As an example of the problem not using PUT can cause, you need look no further than the way in which these very Wiki pages are edited. The edit operation is signified by a query parameter on the Wiki page's URL, "action=edit". This is problematic for two reasons;    (KV)

--MarkBaker    (KY)

The 'action=edit' seems to be fetching an alternate representation of the resource (namely, one that is an HTML form for editing, rather than HTML for reading). When the user activates "Save Changes" in the edit form, it POSTs back to the original resource (without 'action=edit'). If there are side effects to the 'action=edit', this request should indeed be POST (but not PUT).    (KZ)

From a purist point of view, I'm confident that content negotiation would be the means by which an editable version should be retrieved.    (L0)

For the actual update, PUT seems like a more natural fit, in that the user determines the URI, but 2616 seems to intimate that the entity in the PUT request should be the entity returned by future GETs to it. If this is a correct interpretation, POST is more appropriate, because the entity sent to the wiki (a form-encoded wiki-specific markup language) is definately not the entity returned; instead, one is submitting to a "data-accepting process".    (L1)

I'm also quite confident that Wikis should only use PUT. The entity in the PUT request may be the response to a later GET request, but if not, it is an alternate representation of the same resource, which is the important thing from a REST POV. The only role I could see for POST in a Wiki, is for annotations, kinda like what I'm doing here in responding incrementally - I needn't edit the whole document to contribute a paragraph like this one. But then again, annotation would appear to be anti-Wiki.    (L2)

Hmm. 2616 says:    (L3)

Unless otherwise specified for a particular entity-header, the entity-headers in the PUT request SHOULD be applied to the resource created or modified by the PUT.    (L4)

Do we read this as saying that the entity-headers in the request should be reflected in the response?    (L5)

For those that are describing the representation, and if that same representation is retrieved later on a GET, sure. I'm not sure I understand the issue. This isn't surprising, is it?    (L6)

Also, could you give an example of how one would request an editable version of a resource using conneg? At first blush, this seems to be anti-rest, as it explodes the interface; to get a semantically distinct representation of the resource, one must manipulate a third axis of control. Isn't conneg intended only for getting semantically equivalent reprsenetations of a resource?    (L7)

Well, all formats are editable with REST, but some are easier for humans to edit than others. For example, Wiki pages have two representations, HTML and Wiki text, but you wouldn't want to edit the HTML.    (L8)

OK, I see. So to sum up, if Foo is the resource, one gets a text/html representation by default, but can also work with an application/x-wikitext (or whatever) representation (by using GET/PUT/DELETE). Foo?action=edit is just a kludge to get an interface back that lets browsers manipulate the application/x-wikitext format without knowing it.    (L9)

Yes, that's how I see it.    (LA)

I'd be inclinded to think that the form should post back to Foo?action=edit, because it's not application/x-wikitext that's being PUT; it's an url-encoded form that's being POSTed and then digested. If there's going to be kludge, best to limit it to one interface, rather than letting it leak in to the primary resource... this also avoids the entity header issue above.    (LB)

Interesting point. If one PUTs back to a variant URI (which foo?action=edit is), should the "main" resource's state reflect a change? Ick. I'd suggest that a good heuristic would be that you shouldn't directly manipulate the variants, but that any manipulation should occur through the "main" URI.    (LC)

I'd say it doesn't; PUTting to the variant only affects the variant (in this case, I suppose you'd be changing the edit form).    (LD)

--MarkNottingham    (LE)

I think the idea is that, if you have PUT available, you actually edit the resource (as with Amaya, for example), and PUT it back, but if you don't, you use the edit form and POST it. It will be the availability of PUT that frees us from the edit forms. There's not much sense in PUTTING with edit forms, as I see it.    (LF)

-- Tom Passin    (LG)

Meanwhile, development on WikiRPC is in full steam :(    (LH)

I've put up a topic on REST at TWiki:Codev/REST with a pointer to how Amazon are using this. I'm interested in how to apply REST to Wikis, particularly as a way of extending their use to PDAs and other mobile clients (Sun is using a REST-based model for their mobile application example architecture, using J2ME and J2EE with REST as the middleware - see this article ) Hmm, well, I had a hand in the design of that system, and it is most definitely not REST. It's like any other system that uses the Web server for the user interface, and puts the logic in EJBs --MarkBaker    (LI)

I'm also interested in TWiki:Codev/BrowserAndProxyCacheControl (thought I'd mention that, since MarkNottingham is here) and I see this as a key reason to go for a REST architecture to enable caching of such things as RichSiteSummary (a good example of REST by the way, but hasn't really taken off due to lack of really good RSS readers).    (LJ)

-- RichardDonkin    (LK)

When I access a Wiki page with a Web browser, there are several peripheral things added on to the editable resource: There's a header at the top with various global links, and there's an Edit link at the bottom, along with a last modified time. The edit page presents a form that allows the user to post changes to the wikitext representation of just the main body of the page.    (LL)

This discussion makes me wonder if can we decompose this into two distinct layers as follows: First, a pure REST Wiki application, where pages are viewed and edited with GET and PUT, that supports both text/html and text/x-wiki, and that does not have any of that header, footer, or edit page cruft; and second, a Wiki UI application that acts as a user agent relative to the first layer, adding those various UI widgets.    (LM)

This second layer could just as well be a Wiki Browser program implemented as an applet or whatever installed anywhere closer to the user, or just a Web browser that knows about PUT.    (LN)

I'm really trying to understand how REST applies to so-called "Web applications" in general -- and this kind of split comes to mind because it often seems, as in the case of Wiki, that there's some really "core" application for which REST is perfectly natural, but then we've added on all these UI widgets around the page, sometimes as menu bars at the top of the page, or as menus running down the left side of the page, or in the worst case as various frames cluttering the browser window. I've worked in webapp companies for the last few years, and all this stuff has always seemed somehow anti-Web. I keep having this nagging feeling that a true Web application should be more consistently page-oriented (really, resource-oriented), in a way that all this UI cruft ain't. REST makes that feeling more explicit.    (LO)

So, to wrap this up as a question... MarkBaker commented above about a system "that uses the Web server for the user interface, and puts the logic in EJBs". Does it make sense to at least replace the core application, such as the EJB layer in that comment, with a REST architecture, still using a Web server for the user interface? And then can the user interface be implemented in a consistently RESTful way? -- JustinSampson?    (LP)

If there was a single wikitext standard it would be possible to edit it, move it around PeerToPeer?, and only PUT it to central servers when you cared to broadcast your collaboratively built version.    (LQ)

I created a proof of concept Wiki based on REST. I can be found at http://restapi.peterstuifzand.nl/rest/wiki/. The url should probably be a bit different, something like: wiki.peterstuifzand.nl followed by a pagename. Vim and curl can be used to edit the pages. At the moment there is no webbased interface. Maybe there shouldn't even be a webbased interface, but a way to open an URL in another editor instead of the browser.    (6AM)

I think that more programs should understand HTTP. That way you can point a program to an URL and it will GET the resource. When you save it should PUT it again to the same url.    (6AN)