The Cloud CMS API offers a number of convenience API methods that go beyond basic CRUD and bulk content operations. Among these methods are those that allow you to retrieve content from your repository branch in a tree-friendly format. A tree-organized format means that the data comes back in a such a way as to make it easy to load into front-end tree controls.
Typical front-end tree controls requires the ability to load a "snapshot" of the tree as a starting point as well as iteratively grow or expand the tree a future points in time (usually as the end users interacts with the tree). This usually encompasses behaviors such as expanding the children of a folder.
The API method for working with tree responses is:
GET /repositories/{repositoryId}/branches/{branchId}/nodes/{nodeId}/tree
Where nodeId identifies the node at the root of the tree. If you wish to hand back the tree relative to another node, either identify the root node by nodeId or specify a offset path that is relative to the root.
And the following query parameters are supported:
- path - (optional) a path to the root node of the tree being returned (default is "/")
- base - (optional) the path against which all nodes should have their paths resolved (default is path or "/")
- leaf - (optional) a path relative to the base that will be expanded in the returned results (none by default)
- depth - (required) the maximum depth level to dive down in terms of expanding results (default is 1)
- properties - (optional) whether to hand back JSON properties for nodes (default is false)
- containers - (optional) whether to only hand back containers or folders (default is false)
For a call like this:
GET /repositories/1076dcd83a2b7fdd8d38/branches/486dbc4a4cbcbc6e8488/nodes/root/tree?base=/a1/b1
The results might look something like this:
{ "_doc":"fcebbe491fb7fdae8cb7", "id":"fcebbe491fb7fdae8cb7", "repositoryId":"1076dcd83a2b7fdd8d38", "branchId":"486dbc4a4cbcbc6e8488", "rootNodeId":"821c40ab613d9b5bcbbc656b62229301", "title":"b1", "filename":"b1", "label":"b1", "path":"/a1/b1", "typeQName":"n:node", "qname":"o:fcebbe491fb7fdae8cb7", "container":true, "childCount":2, "children":[{ "_doc":"e5be4c648e798587c7a0", "id":"e5be4c648e798587c7a0", "repositoryId":"1076dcd83a2b7fdd8d38", "branchId":"486dbc4a4cbcbc6e8488", "rootNodeId":"821c40ab613d9b5bcbbc656b62229301", "title":"c1", "filename":"c1", "label":"c1", "path":"/a1/b1/c1", "typeQName":"n:node", "qname":"o:e5be4c648e798587c7a0", "container":true, "childCount":0, "children":[] },{ "_doc":"d100978fa368cb9db39a", "id":"d100978fa368cb9db39a", "repositoryId":"1076dcd83a2b7fdd8d38", "branchId":"486dbc4a4cbcbc6e8488", "rootNodeId":"821c40ab613d9b5bcbbc656b62229301", "title":"c2", "filename":"c2", "label":"c2", "path":"/a1/b1/c2", "typeQName":"n:node", "qname":"o:d100978fa368cb9db39a", "container":true, "childCount":0, "children":[] }] }
The depth level is assumed to be 1 (since we didn't provide it). If we provided it, then the children would have children loaded in turn. The example above is typical for situations where you want to lazy-load children of nodes in the tree as the user seeks to expand them. For large trees this essential since it may be impractical or even not possible to load the entire tree up front.