hi francesco, in our offline meeting, we discussed revisions. i think the generic description should also mention the concept of the "last" revision. and we had the idea that any read could report which revision the answer is based on - this would allow to save one roundtrip to get the current revision. in http this could be a custom HTTP header, or it could be part of the response payload.
cheers,david On 03.02.2015 17:43, Francesco Mari wrote: > 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 <mari.france...@gmail.com>: >> 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 <ahani...@gmail.com>: >>> 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}" -- Liip AG // Agile Web Development // T +41 43 500 39 80 CH-8005 Zurich // PGP 0xA581808B // www.liip.ch
