[dna-issues] [JBoss JIRA] Updated: (DNA-312) Implement HTTP GET action for any resource at any path (folder or file)

[ https://jira.jboss.org/jira/browse/DNA-312?page=com.atlassian.jira.plugin... ] Brian Carothers updated DNA-312: -------------------------------- Attachment: DNA-312_for_review.patch Attaching a preliminary patch for review that provides most of the required functionality for the JSON-encoding of a DNA RESTful server (as I understand the requirements), albeit with big holes around PUT support (easy to add), JAAS integration (easy to add poorly), bulk operations over disjoint trees (pretty darn hard to add), and general ease-of-configuration (easy to add). I am throwing this out there in the hopes that it can pass a sanity check from someone else. In lieu of a design document, here are the supported URI patterns, relative to the servlet context in which the WAR is installed. All results are JSON-encoded. / - GET - returns the list of JCR repositories on the server. Example Response (GET - 200): {"JCR%20Repository": {"repository": { "name": "JCR%20Repository", "resources": {"workspaces": "\/resources\/JCR%20Repository"} }}} Note that the response includes a RESTful link to the available resources within the returned repository. /{repositoryName} - GET - returns the list of available workspaces under the given repository. Example Response (GET - 200): {"%3cdefault%3e": {"workspace": { "name": "%3cdefault%3e", "resources": {"items": "\/resources\/JCR%20Repository\/%3cdefault%3e\/items"} }}} Note again the RESTful link to the available resources under the workspace. This could quickly be expanded to support REST-based locking/unlocking and lookup by UUID. Note too the redundant return of the workspace name ("<default>" as URL-encoded). This could easily be changed to return a simple array of workspaces instead of a mapping from the workspace name to the workspace information if that is the desired API. /{repositoryName}/{workspaceName}/items/{path} - GET, POST, DELETE, PUT (future) - reads, inserts, or removes the item at the given path respectively. Example Response (GET - 200): { "properties": {"jcr:primaryType": "dna:system"}, "children": {"dna:namespaces": { "properties": {"jcr:primaryType": "dna:namespaces"}, "children": [ "jcr", "mix", "nt", "dna", "xsd", "sv", "xml", "xmlns", "xsi", "dnaint" ] }} } Note the encoding format - each node contains a hash of properties and a either a hash of nested child nodes or an array of child node names. I had considered having a single for all child items of a node, but there needed to be a way to discriminate between properties and child nodes that have the same name. The example above used the query parameter dna:depth=1 to indicate that one level of child nodes below the requested node should also be returned. Example Request Body (POST) { "properties": { "jcr:primaryType": "nt:unstructured", "testProperty": "testValue", "multiValuedProperty": [ "value1", "value2" ] }, "children": {"childNode": {"properties": {"nestedProperty": "nestedValue"}}} } Example Response (POST - 201) { "properties": { "testProperty": "testValue", "jcr:primaryType": "nt:unstructured", "multiValuedProperty": [ "value1", "value2" ] }, "children": {"childNode": {"properties": { "nestedProperty": "nestedValue", "jcr:primaryType": "nt:unstructured" }}} } Note that the response includes the nested nodes that were created as well as the parent. Note also how the jcr:primaryType property was filled in for the nested child node. Since no primary type was specified for the child node in the request, Session.addNode(String) was called internally and the default primary type was used. Example Reponse Body (DELETE - 204) Deletes do not return a response. A successful delete can be determined by a 204 (NO CONTENT) response code. -- 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