As explained in the introduction, the REST API is based on a very limited list of general principles:
...
| Code Block | ||
|---|---|---|
| ||
GET /content/objects/59/versions/2/relations&limit=5 HTTP/1.1 Accept: application/vnd.ez.api.RelationList+xml |
| Info | ||
|---|---|---|
| ||
Resources that accept a reference to another resource expect this reference to be given as a REST ID, not a Public API ID. As such, the URI to request users that are assigned the role with ID 1 would be |
Custom HTTP verbs
In addition to the usual GET, POST, PUT and DELETE HTTP verbs, the API supports a few custom ones: COPY, MOVE (http://tools.ietf.org/html/rfc2518), PATCH (http://tools.ietf.org/html/rfc5789) and PUBLISH. While it should generally not be a problem, some HTTP servers may fail to recognize those. If you face this situation, you can customize a standard verb (POST, PUT) with the X-HTTP-Method-Override header.
...
Both methods are always mentioned, when applicable, in the specifications.
Specifying a siteaccess
One of the principles of REST is that the same resource (Content, Location, ContentType, ...) should be unique. The purpose is mostly to make it simple to cache your REST API using a reverse proxy like Varnish. If the same resource is available at multiple locations, cache purging becomes much more complex.
Due to this, we decided not to enable siteaccess matching with REST. In order to specify a siteaccess when talking to the REST API, a custom header, X-Siteaccess, needs to be provided. If it isn't, the default one will be used:
| Code Block | ||||
|---|---|---|---|---|
| ||||
GET / HTTP/1.1
Host: api.example.com
Accept: application/vnd.ez.api.Root+json
X-Siteaccess: ezdemo_site_admin |