[dna-issues] [JBoss JIRA] Commented: (DNA-309) Design URLs, leaving room for future UI features and maybe WebDAV

[Randall Hauch (JIRA)]

    [ https://jira.jboss.org/jira/browse/DNA-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12458131#action_12458131 ] 

Randall Hauch commented on DNA-309:
-----------------------------------

The most obvious first approach for a URI design is to directly represent each node in the repository as a resource, and to map the repository operations to GET (read), PUT (update/create), POST (create), and DELETE (delete).  For example, "/a/b/c/d" would identify the node "/a/b/c/d".  A "GET /a/b/c/d" request would obtain a representation of the "/a/b/c/d" node.

Perhaps the first challenge to this approach is whether to also treat properties as resources.  If each property were treated as a resource, then the URI design would have to distinguish a node property named the same as a that of a child of the same node.  For example, if a node /a/b/c in the previous example contained a child "d" and a property "d", then is "/a/b/c/d" referring to the node or the property?  One option is to distinguish properties with a character ('@' comes to mind), although which character would depend on URL escaping requirements.  It probably is possible to require this character only when there is a child with the same name as a property name (something that is not too frequent, I expect).

The kind of resource to return (e.g., JSON, XML, HTML, etc.) should be driven by the "accept" HTTP header, which specifies the media ranges (mime types with optional parameters) that are being requested.  Multiple mime types can be specified, with precedence rules and quality factor denoting the preferred order.  See http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html  By using the HTTP header, the URI no longer needs to deal with extensions or any other mechanism to denote the desired response format.  And this means that the URI design can more closely match the resource names.  Here's an example of a GET request to obtain a JSON representation of node "/a/b/c/d":

 GET /a/b/c/d
 Host: myhost.example.com
 Accept: application/json

URI query parameters are useful to supply additional criteria and information about the representation to be returned, such as depth of the representation or reading just the properties or children.  This seems to be an acceptable way of affecting the representation.

What about operations, like move or copy?  One choice is to use query parameters (e.g., PUT with a "?moveTo=/a/b/e" or POST with a "?copyOf=/a/b/e").  Another option would be to allow actions or operations in the representation that is PUT by the client.  The following example is an HTTP request to move node "/a/b/c/d" to "/a/b/e" and simultaneously set the "jcr:title" property to "This is a new title":

 PUT /a/b/c/d
 Host: host.example.com
 Accept: application/json
 Content-Length: nnn
 Content-Type: application/json
 
 {
   "dna-action:moveTo": "/a/b/e"
   "jcr:title" : "This is the new title"
 }

> Design URLs, leaving room for future UI features and maybe WebDAV
> -----------------------------------------------------------------
>
>                 Key: DNA-309
>                 URL: https://jira.jboss.org/jira/browse/DNA-309
>             Project: DNA
>          Issue Type: Sub-task
>          Components: Web Application
>    Affects Versions: 0.3
>            Reporter: Johnny Verhaeg
>             Fix For: 0.5
>
>
> For right now, we need URLs for just publishing and un-publishing content.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira