As explained in the introduction, the REST API is based on a very limited list of general principles:
- each resource (uri) interacts with a part of the system (Content, URL aliases, user groups...),
- for each resource, one or more verbs are available, each having a different effect (delete a Content, get a URL Alias, list user groups...),
- media-type request headers indicate what type of data (Content / ContentInfo), and data format (JSON or XML), are expected as a response, and what can be requested.
General expectations
GET
This verb is used to query the API for information. It is one of the two operations web browsers implement, and the most commonly used.
The only requirement for this verb is usually the resource URI, and the accept header. On top of that, cache request headers can be added, like If-None-Match, but those aren't fully implemented yet in eZ Publish 5.0.
Load ContentInfo request
The API will reply with a few headers, as well as with the ContentInfo for content with ID 23 in XML format, as specified in the Accept header:
Load ContentInfo response
We can learn three things from those response headers:
- The length of our content. It doesn't really matter that much...
- What we are receiving, here, a ContentInfo (
Content-Type: application/vnd.ez.api.ContentInfo) in XML (Content-Type: application/vnd.ez.api.ContentInfo+xml) - We can modify the received content by patching (
Accept-Patch: application/vnd.ez.api.ContentUpdate+xml;charset=utf8) it with a ContentUpdate (Accept-Patch: application/vnd.ez.api.ContentUpdate+xml;charset=utf8) in XML (Accept-Patch: application/vnd.ez.api.ContentUpdate+xml;charset=utf8)
This last part means that if we send a PATCH /content/objects/23 request with a ContentUpdate XML payload, we will update this Content.
The XML body is a serialized version of a ContentInfo struct.