The OWNS-tree structure is used for file system trees.
Paths start with the root's UUID.
Following path segments do use the elements names by default, and their UUID for fallback. Only using UUIDs is supported, although not recommended (non technical users are likely preplexed when they see a file system path with "cryptic" alphanumeric character sequences, also 36+ chars per level for UUIDs would use up the 256 (?) limit of Windows quite fast).
If there is a conflict with names, then the element's UUIDs MUST be used, accessing .../name results in 404 or redirect to the last folder which can be determined (TBD).
Elements which own other elements are displayed as collections within WebDAV.
Collection elements which have a binary file attached to them have a special "magic" file called _self placed within them. This is required for most existing WebDAV clients to access this data.
Elements which do not own other elements but have a binary file attached to them are displayed as a normal file.
All elements, regardless if they are a collection, item or elements without a binary file, do have a special .<name>.properties.json file within the WebDAV mount, which contains the same data as when accessing GET /<uuid> of the same element directly. This makes sure that the API's data are still accessible through WebDAV and can be easily queried with normal tools such as jq. The dot at the file name's start ensures that it is hidden by default and only shown to users which are more likely to understand their use.
HAS_READ_ACCESS-relations are mapped as links to new filesystem mounts.
Other relations are currently not mapped to WebDAV elements. If there is a good way, please comment! :D
Recursive paths should not be a problem, as Cypher queries themself do not visit the same node twice.
Breaking Changes
WebDAV requires that LOCK calls to non existing resources create them directly, to be later filled/changed by the client. This would require the use of default fallbacks for the element's id (random UUID, no problem) and its type (currently not changeable, static). As the type can not be specified and later not be changed, the API is likely to add support for changing an element's type after creation. This requires modification of the request body for the PUT and PATCH calls against /<uuid>.
TBD: Should all WebDAV calls be fenced within a sub path, e.g. /webdav? This would help to separate different domains with different standards and requirements, and would allow other similar standards to be implemented in the future in similar ways. Furthermore, WebDAV requires error messages to be returned in XML, not JSON. Therefore it would be difficult to differentiate between a normal API call and a WebDAV call against first level elements, and send appropriate error messages back.
The graph-to-tree-mapping is mostly worked out:
OWNS-tree structure is used for file system trees._selfplaced within them. This is required for most existing WebDAV clients to access this data..<name>.properties.jsonfile within the WebDAV mount, which contains the same data as when accessingGET /<uuid>of the same element directly. This makes sure that the API's data are still accessible through WebDAV and can be easily queried with normal tools such as jq. The dot at the file name's start ensures that it is hidden by default and only shown to users which are more likely to understand their use.HAS_READ_ACCESS-relations are mapped as links to new filesystem mounts.Breaking Changes
LOCKcalls to non existing resources create them directly, to be later filled/changed by the client. This would require the use of default fallbacks for the element's id (random UUID, no problem) and its type (currently not changeable, static). As the type can not be specified and later not be changed, the API is likely to add support for changing an element's type after creation. This requires modification of the request body for thePUTandPATCHcalls against/<uuid>./webdav? This would help to separate different domains with different standards and requirements, and would allow other similar standards to be implemented in the future in similar ways. Furthermore, WebDAV requires error messages to be returned in XML, not JSON. Therefore it would be difficult to differentiate between a normal API call and a WebDAV call against first level elements, and send appropriate error messages back.