WikiMachineInterfaceStandard

MeatballWiki | RecentChanges | Random Page | Indices | Categories

This page is essentially an application of HTTP (RFC 2616) and the REST philosophy to wikis. The primary points:

Every page is given a canonical URI (ideally the root URL + the canonical page name, with no extension).

All access to a page's content is done via that URI. No query munging needed.

Every site-wide function is given a canonical URI.

This page does not cover feature discovery, the ability for a machine to automatically determine the functionality provided by a wiki.

RFC 2616

As much of RFC 2616 as is applicable should be supported. This includes, for instance:

Emitting the most informative HTTP response codes in all situations.
Providing ##Content-Length##, ##Content-MD5## and ##Content-Type## headers.
Supporting ##HEAD## requests.
Providing ##Last-Modified## and ##Etag## headers, and supporting conditional requests based on the same.
Supporting ##Expect## headers in requests.

Any particular should only be ignored if it is impossible to support it, e.g. due to a bug in a web-server's implementation.

HTTP GET

To read a page, use a HTTP GET on the URI. Negotiation for type must be done with the ##Accept## header, and if multiple return types are provided by the URI, the ##Vary## header must be set in the response. Language negotiation, if supported, must also be done according to HTTP specifications. Alternative locations that provide only single formats are allowed.

HTTP PUT

To create a new page, use a HTTP PUT on the URI. To modify an existing page, use a HTTP PUT qualified with either ##If-Unmodified-Since## or ##If-Match## headers. A wiki MUST reject an unqualified PUT if the page already exists.

Version annotation is done via the extension header ##Change-Digest##.

Content-Encoding## must be respected. ##text/wiki## is a non-standard format meaning "whatever your wiki uses". ##text/plain## must be emitted exactly as given, with no destructive markup. (Automatic linking of CamelCase is OK as the text is not altered.) ##text/html## can be rejected if the wiki does not support it, if malformed HTML is passed in, or if illegal HTML tags are used. A similar approach should be used for ##text/xhtml## and others.

HTTP DELETE

Page deletion should be done via a HTTP DELETE request. A wiki that supports immediate page deletion can satisfy such a request immediately. Those that demand PeerReview of page deletion MUST return a status of ##202 Accepted## if the DELETE will be processed after review.

WebDAV extensions

Page history is to be provided using WebDAV HTTP extensions.

Other functions

Other functions, like search, update feeds, et cetera, should be provided via canonical URIs. These will be covered in a future revision of this standard.

Discussion

Hey folks I'm currently not caught up with this page or with the mailing lists, but a group of people at the Wiki Architecture group in the InterWiki workshop of WikiSym 2005 were talking about a RESTful standard too; I assume you're talking with them?

See

http://ws2005.wikisym.org/space/WSR+3

I went to another group halfway through, but I gather from that page that Max is working on a spec.

-- BayleShanks

In fact, shortly after I wrote that, I got this email:

Hi Wikians,

  at http://www.wikisym.org/wiki/index.php/WSR_3
  we just relaunched our efforts to create wiki interoperability.


  You can/should contribute in the 'Work' section.
  Especially http://www.wikisym.org/wiki/index.php/WikiStructure
  needs  more  input.  How  can  we  model a wiki page structure - and
  capture  80%  of the features from 80% of the popular wiki engines -
  or something like that.

  'Help the wiki community to become interoperable'

Kind Regards,
  Max Voelkel

CategoryWikiTechnology CategoryWikiStandard