What you are proposing is a REST interface where every node can be treated as an individual resource. This will not work. To fully leverage the MVCC architecture of Oak, a set of related GET, POST, PUT and DELETE requests must belong to the same context. This context, in Oak, is represented by a ContentSession. To express the fact that two or more requests belong to the same ContentSession, the API must provide the following functionalities:
1. Open a session. This returns a session ID that must be saved by the client. 2. Require a valid session ID on every following POST, PUT, DELETE and GET method. 3. Commit or discard a session. This also require a session ID, obviously. This solution forces the server to maintain ContentSession instances. When a client opens a session on an instance of the server, it is bound to that server instance until the ContentSession is committed or discarded. This approach enforces a really strict constraint on the horizontal scalability of the server. We can still provide a REST API, but to avoid this constraint we have to make the API a little bit more coarse grained. In this case we have to work with trees, and not with single nodes (technically speaking, a node is a tree with depth zero, but let's ignore it for the sake of the explanation). The root of the repository is the root of the tree we are working on. Every tree in the repository (the root or any sub-tree of the root) supports a GET method that allows reading that tree, optionally filtering out properties and children and enforcing the maximum depth to read. The root of the repository is a special tree that also supports a PATCH method. This method allows the client to specify a set of operations to make the tree move from one valid state to another valid state. The PATCH operation is not bound to any session, is atomic and can be performed by any instance of the server. This is my analysis so far. I am open to any solution that would combine these qualities: 1. makes effective use of the MVCC approach of Oak. 2. is complaint to the REST architecture. 3. enables horizontal scalability by eliminating state on the server. 2015-01-26 13:00 GMT+01:00 Felix Meschberger <[email protected]>: > +100 ! > > * Type=remove is exactly DELETE and we should do it > * type=add is just PUT or POST > * type=set likewise is just PUT or POST > * type=unset is exactly DELETE > > So, please use those. > > Regards > Felix > > >> Am 26.01.2015 um 10:00 schrieb Lukas Kahwe Smith <[email protected]>: >> >> >>> On 26 Jan 2015, at 09:55, Francesco Mari <[email protected]> wrote: >>> >>> I think a multi-tree read request could be a good improvement to the >>> API. Technically speaking, it may be though as a generalization of the >>> "Read tree" operation. >> >> can you elaborate why you are using an RPC style protocol, rather something >> more along the lines of REST. >> >> for example: >> { >> "type": "remove", >> "path": "/a/b/c" >> } >> >> could just be a DELETE on /a/b/c >> >> regards, >> Lukas Kahwe Smith >> [email protected] >> >> >> >
