XWiki provides fine-grain access to virtually every element through an API that is based on HTTP semantics, i.e., a RESTful API. In this page you will find all the details to take advantage of this API and the instructions to use it at its full potential.

Accessing the service

By defaut the XWiki RESTful API entrypoint is rooted at the following URI:

For example the /wikis resources on a server running on localhost on port 8080 can be retrieved using the following URL : http://localhost:8080/xwiki/rest/wikis

In addition to retrieving content in XML format, you can also retrieve it in JSON format by adding the parameter ?media=json in the URL. For example: http://localhost:8080/xwiki/rest/wikis?media=json

Dataset

This section contains a brief and high-level description of the XWiki data set that should serve as a basis for presenting resources and their associated operations.

XWiki has pages organized in spaces. Each page is available in multiple versions (its history) and translations. Translated pages have their own versions and history which are independent. Each page might have attachments. Each attachment has its own history. Attachments are shared among all the different translations of a page (i.e., the same set of attachments is the same regardless of the page language). Pages can have one or more objects. Objects are instances of a class that contains a set of properties. Some objects might be directly exposed as first class entities, such as comments and tags. Objects, as attachments, are shared among all page translations.

Understanding resources and representations

"An important concept in REST is the existence of resources (sources of specific information), each of which is referenced with a global identifier (e.g., an URI in HTTP). In order to manipulate these resources, components of the network (user agents and origin servers) communicate via a standardized interface (e.g., HTTP) and exchange representations of these resources (the actual documents conveying the information)." (Wikipedia)

Resources in XWiki are pages, attachments, objects, properties, spaces, and all the things we described in the previous section. XWiki has a default way of conveying the information about these resources, i.e., by providing well defined XML representations that contain all the information associated to the resource in an XML format. This format is described using an XML Schema Definition file.

Of course the same resource can be represented in many different ways. This is yet to be documented.

Another important aspect of representations is that they contain useful information for linking related resources. This is a realization of the Hypermedia As The Engine Of The Application State (HATEOAS) principle. In XML representations this information is conveyed through the <link> tag. This tag has two important parameters: rel and href. rel specifies the "semantics" of the link, while href is the URI of the linked resource.

For example, in the representation of a page, we can have links to the comments, tags, attachments which are independent resources associated to the current page. These links are provided in the XML representation of a page and allow a client to navigate to related resources... Like we do every day when we click on a link in a web page.

Relations

The available relations that you might find in the XML resource representations are the following:

Rel

Semantics

http://www.xwiki.org/rel/wikis

The representation containing the list of virtual wikis.

http://www.xwiki.org/rel/spaces

The representation containing the list of spaces in a wiki.

http://www.xwiki.org/rel/pages

The representation containing the list of pages in a space.

http://www.xwiki.org/rel/translation

The representation containing a translation of a page.

http://www.xwiki.org/rel/page

The representation for a page.

http://www.xwiki.org/rel/space

The representation for a space.

http://www.xwiki.org/rel/parent

The representation for the page that is parent of the current resource.

http://www.xwiki.org/rel/home

The representation for the page that is the home of the current resource.

http://www.xwiki.org/rel/attachmentData

The representation of the actual attachment data.

http://www.xwiki.org/rel/comments

The representation of the list of comments associated to the current resource.

http://www.xwiki.org/rel/attachments

The representation of the list of attachments associated to the current resource.

http://www.xwiki.org/rel/objects

The representation of the list of objects associated to the current resource.

http://www.xwiki.org/rel/object

The representation for an object.

http://www.xwiki.org/rel/classes

The representation of the list of classes associated to the current resource.

http://www.xwiki.org/rel/history

The representation of the list of history information associated to the current resource.

http://www.xwiki.org/rel/class

The representation for a class.

http://www.xwiki.org/rel/property

The representation for a property.

http://www.xwiki.org/rel/properties

The representation of the list of properties associated to the current resource.

http://www.xwiki.org/rel/modifications

The representation of the list of modifications associated to the current resource.

http://www.xwiki.org/rel/children

The representation of the list of children associated to the current resource.

http://www.xwiki.org/rel/tags

The representation of the list of tags associated to the current resource.

http://www.xwiki.org/rel/tag

The representation of a tag.

http://www.xwiki.org/rel/search

The representation for a search resource.

http://www.xwiki.org/rel/syntaxes

The representation for a syntax resource.

Relations are defined as URIs in order to provide a sort of namespace. Currently these URIs are not links to real web pages but, in the future, they might point to descriptions of their semantics on actual web pages (or other kinds of representations).

The "HATEOAS" Graph

In order to better understand the relations among resources you might have a look at this graph that pictures all the resources available in the XWiki RESTful API and the relations among them. In this graph, nodes are URI templates representing classes of resources. Edges are the possible links that you might find in a representation of a given resource, and their associated relations.

This graph shows that by starting from the API entry-point a client can navigate and discover all the resources just by following the links provided in representations (and by knowing their semantics). This was exactly the way how this graph was generated.

Interacting with the XWiki RESTful API

The XWiki RESTful API is accessible through HTTP so, in principle, you can use every client that is capable of "speaking" HTTP in order to interact with it. Even a web browser!If you want to write more complex programs you might download an HTTP library for your favorite language (e.g., http://hc.apache.org/).

Java users might take advantage of the JAXB framework and its XJC binding compiler in order to generate domain object models directly from the XML Schema Definition, and use them for serializing and de-serializing XML representations.

If you use this approach (Apache HTTP Client + JAXB) you will find yourself writing some code like this:

And you will have all the information about the Main.WebHome page in the Page object, without the need of handling XML directly.

Because of the wide variety of HTTP frameworks available we don't provide a full tutorial about using them. However, in order to show you how to interact with the XWiki RESTful API, we will use curl: a standard command line HTTP client that provides an interface to all the functionalities of the HTTP protocol.

Authentication

XWiki session: If you are logged in XWiki and you use the cookies provided by the authentication mechanism, you will also be authenticated to the XWiki RESTful API. This is useful, for example, when you are interacting with the API using the XMLHttpRequest object of a browser using Javascript.

If you don't provide any credentials the XWiki RESTful API will recognize you as a XWiki.Guest user.

Sending representations

Many resources are modifiable, so you can send representations in order to change the state of those resources (e.g., pages).All modifiable resources accept XML representations that conform to the XML Schema Definition. However, some other representations might be accepted as well (see the following sections).

Resource update is usually done by using the PUT method, while resource creation is done via PUT or POST.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?><pagexmlns="http://www.xwiki.org"><title>Hello world</title><syntax>xwiki/2.0</syntax><content>This is a new page</content></page>

The page has been created and is accessible. Subsequent PUT requests to the page URI will modify its content.

You can specify a subset of the three elements title, syntax, and content in the XML when updating/creating a page.For example, if you just want to change the title, it is sufficient to specify only the title element. The current content and the syntax of the page will be left unchanged.

Overcoming browser limitations

As said before, it could be useful to send information by using browser's XmlHttpRequest objects. However, currently many browsers only support GET and POST methods, so it is impossible to send, for example, PUT requests. In order to overcome this limitation you can override the HTTP Method by specifying a method parameter in the URI query string.

In the previous example, if you send a POST request to the http://localhost:8080/xwiki/rest/wikis/xwiki/spaces/Main/pages/NewPage?method=PUT it will be interpreted as if it were an actual PUT request.

This overriding mechanism allows the interaction with the XWiki RESTful API by using any kind of browser.

PUT vs POST

In the following sections you will see that sometimes resources are created by using PUT and sometimes by using POST. The general principle is that if the client is responsible for choosing the resource URI then PUT is used. If it's the server that bears this responsibility, then POST is used.

To be clearer, when a client wants to create a page it knows where that page should go, so it is able to communicate the server the target URI. PUT is used.

A client, on the contrary, cannot know beforehand what will be the URI of a comment, since comment URIs contains the ID of the comment and this information is generated by the server. In this case the client will do a POST and the server, in response, will communicate the URI it generated for the newly created comment.

XWiki RESTful API Documentation

In this section you will find the documentation of the whole XWiki RESTful API.

[since 6.4] using a SOLR query (handled by the SOLR Query module) on the wikis that are specified as a comma separated list in the wikis parameter. If className is specified, the result will also contain the data for the first object of the corresponding class.

[before 6.4] using a Lucene query (handled by the Lucene Plugin) on the wikis that are specified as a comma separated list in the wikis parameter. If className is specified, the result will also contain the data for the first object of the corresponding class.

Description: The list of pages in the wiki {wikiName}. Filters can be set for the name, space and/or author to include only pages that match the given filters. This resource can be used to search for pages in a wiki.

Description: The list of attachments of pages located in a given {spaceName}. Filters can be set for the name, page, author and/or types (comma separated list of strings) to include only attachments that match the given filters. This resource can be used to search for attachments in a space.

Description: The list of attachments in a given {wikiName}. Filters can be set for the name, page, space, author and/or type (comma separated list of strings) to include only attachments that match the given filters. This resource can be used to search for attachments in a wiki.

Starting from release 4.3M2, the RESTful API modules have been refactored so that now resource declarations are available in a separate module.This means that all the information about resources, i.e., URI Paths, supported methods, query parameters, and so on, are available to module developers without having to include the big REST Server module.

Clients willing to access/use the REST API can then declare a dependency on xwiki-platform-rest-api and have all this information available for interacting with it. There are two use cases for this:

Another platform module that wants to generate responses with links to existing resources.

HTTP clients that wants to make requests to the RESTful API.

The xwiki-platform-rest-api module can be also seen as an authoritative reference for the REST API.

Using the RESTful API

Highlevel description and tutorial for a basic usage of the RESTful API

The advantage of the second approach is that curl will take care of url-encode your content, while if you send a file you are responsible for this.

Remarks:

In the application/x-www-form-urlencoded format the "property#" is a standard immutable prefix that is used to distinguish attributes referring to property values from the attributes referring to the object. For example if we had className=XYZ&Text=FOO we would have had an ambiguity on className because we couldn't understand if className is a property of the object to be set to XYZ or an attribute that describes the object itself (i.e., its metadata like the className). By having the property# prefix this ambiguity is resolved.

The information you get back when you retrieve an object (i.e., allthe <attribute> elements) are useful when clients need to understand the type of data contained in an object (e.g., when they want to display it). They are not necessary when creating an object because the system already has this information. That's why the XML to be sent is smaller. Actually the only information needed is the <className> and a set of <property name="..."><value> elements.

How do you know what kind of information you can send with the XML? You can discover it by using the class description URI. If you go to http://localhost:8080/xwiki/rest/wikis/xwiki/classes you will get a list of all the classes defined in the Wiki. By looking at this you will understand what are the properties defined by each class, their types and attributes. In that way you will know what you're allowed to put in the <property><value> elements of the XML you send.