Resource nesting
As mentioned above, most resources are nested in a hierarchical structure.
For example the "folders" resource is nested under the "projects" resource.
Resource nesting is also reflected in the URI structure.
For example "/projects/123/folders/234" represents the URI for a folder with the
identifier '234', which is associated with the project identified by '123'.
Content negotiation
All resource endpoints (but not the authentication endpoint) support HTTP 1.1
content negotiation mechanisms.
The following content types are supported:
-
application/json
(the default)
-
application/xml
Example:
To demonstrate content negotiation, the above request and response for a list
of projects could be rephrased as:
GET /api/projects HTTP/1.1
Authorization: Bearer example-token
Accept: application/json
and:
HTTP/1.1 200 OK
Content-Type: application/json
[{"id":1,"name":"First project"},{"id":2,"name":"Second project"}]
Notes on XML formatting
Due to XML best practices on attribute naming, all underscores (ASCII 0x5F, '_')
are replaced by dashes (ASCII 0x2D, '-'). So for example the "project_id" attribute
of a "folders" resource would become "project-id".
Example:
This example shows the request and response for a single "projects" resource in XML.
GET /api/projects/7 HTTP/1.1
Authorization: Bearer example-token
Accept: application/xml
HTTP/1.1 200 OK
Content-Type: application/xml
<?xml version="1.0" encoding="UTF-8"?>
<project>
<id>7</id>
<name>Example Project</name>
<starts-at>2013-07-17</starts-at>
<ends-at>2055-01-01</ends-at>
</project>