[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: URL-Patterns and JSON-Schemas
HI all, as discussed in our last BB call I have updated the Excel sheet. For those who have missed the call: The purpose of the Excel sheet is to collect the important design aspects on a single page. It defines the URLs, http methods, request and response types and maps those to the CMIS domain model. While the first version posted was a more general approach I tried to align this now better to the existing URL patterns and Orderly schema definitions. Please be aware that the attached version is nothing but a working copy. Likely I won’t find much time to improve this before our next call. So it might be better to give you some time to take a look at the current state. Given the current proposals (cmis-schema-v0.1-browserbinding.json and CMIS-677) I ran into a bunch of issues that need more discussion. Perhaps I missed something, but following the existing URL pattern with the id as URL parameter for me it is unclear at the moment: Orderly Schema: ---------------------- Missing schema elements: repositoryInfoList typeHierarchy folderHierarchy objectList (response for getCheckedOutDocs) query and queryResponse(?) alias names, etc. URL Patterns: ----------------- A couple of URLs need to be defined on root level: query checked-out content-changes The query parameter object-id is not sufficient. Other id parameters we need are: repositoryId typeId versionId(?) We also could use one parameter being more general, like “id” More action parameters needed: checkout move deleteTree (could also be a URL parameter recursive=true) updateContent addToFolder, removeFromFolder More selectors needed: parent(?) parents folders renditions relationships properties versions acls policies allowableActions I also believe that the current action mechanism is insufficient for content, ACLS and policies The action-param works well for aspects that are read-only (like allowableActions, renditions). But other aspects of a document allow further actions to be applied on them: content, properties, ACL, policy. If I have a URL to an object and action=update… how can I distinguish between updateProperties and updateContent? I see several possibilities: separate URL for object and content change the rule: Instead of a "selector" parameter an "action" parameter MUST be passed. (solution: allow both) distinguish the requested action only from the JSON in the request body: If this contains properties then properties are updated If this contains content then content is updated. Have a separate actions “updateContent”, “addAcl”, …. Did we already have an answer for this? I wondered what the best way is to reference the URL for each service method and came up with a grammar like approach. Not sure if we want to keep this… Feel free to update or correct the sheet where necessary… Jens |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]