At the beginning I wanted to expose a more granular interface for node
operations, mapping every node to a fully REST resource. I figured out
that this has some drawbacks.
First of all, you have to create some kind of context between HTTP
requests to guarantee that operations happen in your transient space
and don't influence other clients. The only solution I found was to
open a session on the server, assign an ID to it, and force clients to
include the session ID on every request. To persist the changes made
in a session, the client had to explicitly commit it. This way I could
guarantee repeatable reads and isolated writes.
This means that the server has to maintain multiple ContentSession
objects and a mapping between session IDs and ContentSessions. This
pushes a lot of state on the server and avoid horizontal scalability.
When a client opens a new session, it is bound to the server holding
the session.
To have a scalable solution, I had to push some complexity and state
to the client. The only way a client has to perform change to the
repository is to provide a patch - a series of operations - that would
represent the steps to perform to bring the repository to the wanted,
final state. The server can then apply those steps and persist the new
state in the repository. Note that a patch can be processed by any
server in a clustered deployment, because the client is not bound to
any specific instance.
2015-01-26 10:00 GMT+01:00 Lukas Kahwe Smith <sm...@pooteeweet.org>:
>
>> On 26 Jan 2015, at 09:55, Francesco Mari <mari.france...@gmail.com> 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
> sm...@pooteeweet.org
>
>
>
