In an offline meeting today, it was noted that the specified handling of binaries should be revised. Currently, any user is able to create binary objects, even if those objects are never assigned as a value to binary properties. This may open the (unwanted) possibility for the repository to be misused as a binary object store.
On the other hand, it is not always possible or wanted to inline a binary object inside a JSON patch. Another mechanism is needed to include arbitrary binary objects inside a PATCH request, and to associate these binary objects to the content specified in the patch. Any binary object included in the PATCH request that is not used by the patch content should be ignored by the server. I am currently investigating a way to define a multipart PATCH request, whose parts can represent a patch or a binary object. Any other idea is welcome. 2015-02-03 17:43 GMT+01:00 Francesco Mari <[email protected]>: > I created a couple of pages in the Jackrabbit wiki. The first [1] is > the generic description of the operations that you probably already > read, The second [2] is a draft of the REST API that exposes the > concepts exposed in [1] using HTTP as a transport protocol. > > Any feedback is welcome. > > [1]: https://wiki.apache.org/jackrabbit/frm/RemoteOperations > [2]: https://wiki.apache.org/jackrabbit/frm/HttpOperations > > 2015-02-02 17:34 GMT+01:00 Francesco Mari <[email protected]>: >> I am currently working on a REST API, that looks similar to what you >> are proposing. I should have something to show really soon. >> >> 2015-02-02 15:33 GMT+01:00 Axel Hanikel <[email protected]>: >>> Hi, >>> >>> I’m not sure if I have enough background to participate in the discussion, >>> so bear with me... >>> >>> I think it wouldn’t be too hard to translate oak operations to an >>> HTTP-based API, if we just define some URLs as “special”, i.e. they don’t >>> represent the corresponding node in the repo but have special semantics. >>> For example, /sessions could represent sessions or transactions, which have >>> to be committed or discarded, or which are discarded automatically after >>> they expire. >>> >>> Below are some example requests (responses are: status code - response >>> header; everything after # is a comment): >>> >>> Req: GET / # Get current revision >>> Resp: 302 - Location: /revisions/12345678-abcd-abcd-abcd-123456789abc >>> >>> Req: GET /sessions >>> Resp: 302 - Location: /sessions/12345678-abcd-abcd-abcd-123456789abc >>> # possibly several location headers if more than one session available for >>> the user (if we want to allow that) >>> 204 - # No sessions >>> >>> Req: POST /sessions # start a new session >>> Resp: 201 - Location: /sessions/12345678-abcd-abcd-abcd-123456789abc >>> >>> Req: PUT /sessions/12345678-abcd-abcd-abcd-123456789abc # Commit >>> session >>> Resp: 201 - Location: /revisions/12345678-abcd-abcd-abcd-123456789abc >>> # Success >>> 409 - # Merge conflict >>> ... >>> >>> Req: GET /some/path # read a node (the node’s current value) >>> >>> Req: GET /sessions/12345678-abcd-abcd-abcd-123456789abc/some/path # >>> read the same node’s value at the time the session was created >>> >>> Req: GET /some/path/@prop # read a node’s property >>> >>> Req: PUT /some/path/@prop # create or replace property “prop” and >>> commit immediately >>> >>> Req: PUT >>> /sessions/12345678-abcd-abcd-abcd-123456789abc/some/path/@prop # create or >>> replace property “prop” within the session >>> >>> Req: DELETE /sessions/12345678-abcd-abcd-abcd-123456789abc # discard >>> a session >>> >>> Req: GET >>> /revisions/12345678-abcd-abcd-abcd-123456789abc/path/to/node # read a >>> revision >>> >>> Req: GET >>> /trees/12345678-abcd-abcd-abcd-123456789abc/path/to/root/of/subtree # read >>> a tree, output format can be json or anything, depending on Accept header. >>> Range header could limit output. >>> >>> Authentication is done in the usual HTTP way. >>> >>> WDYT? >>> Axel >>> >>> PS: The "special nodes" are probably better named >>> "/jcr:system/remote/{sessions,revisions,trees}"
