I written a couple of REST services and clients over the past years and it is always a subject of discussions: How to map transactions with a stateless RESTful service?
We always did it like Neo4j, every REST call is a implicit transaction. If this is not sufficient we implemented BULK or combined calls for bulk deletions or creations etc. But the question is: Is it really impossible to implement transactions? We can use - the session context with invalidating a session or timeout is a rollback (this will be expensive...) - or POSTing a new transaction returning a Trx ID, subsequent write or update operations are containing a transaction ID - using custom HTTP header - (whatever) All this violates the stateless paradigm. But the reality of the Web is: we do have HTTP sessions, cookies, baskets etc. And scalability is a question of server implementation, isn't it? What do you think? On Mon, Dec 20, 2010 at 12:28 PM, Jim Webber <j...@neotechnology.com> wrote: > Hi Ido, > > Those make good sense. And I think I have some reasonable RESTful > approaches in mind for tackling them which don't need transactions (using > Ian Robinson's typed links to forms approach here). > > 1. Bulk create of nodes and relations: > - PUT a set of nodes and relations to the server, relative to some node, > or to the graph itself. > > - Work needed: define a graph format (e.g. using JSON) to describe nodes > and relations. > > 2. Remove relations: > - GET a "removal form" (optional, will be cacheable for a long time > anyway) > - Populate the removal form with the nodes to be deleted, POST it to the > server > - Server responds with the URI of a (transient) resource that represents > all the nodes and relations you previously specified. > - DELETE the transient resource > > - Work needed: design a "removal form" (effectively a deletion manifest), > a little processing logic on the server side > > 3. Clone subgraphs > - Use a form to select a start node, terminating condition (e.g. depth), > POST its URI to the cloning URI with a traversal description (or just > something as simple as a termination condition for a df/bf search) which > itself is created by filling in a form. > > - Work needed: a clone algorithm for the server; form that allows us to > describe the graph for the clone; URI to POST back the form to the graph. > > > > OK, so there's some substantial work to be done here. But there's a > positive point to take away from this. In the latest milestone release we > have a Plugin mechanism where end users are able to extend the behaviour of > graphs/nodes in order to implement all these kinds of domain specific > things. > > Right now as we're testing the new Plugin stuff, I'm going to implement a > simple clone subgraph plugin. I'll post the code and the wire-level HTTP > here when I'm done so you can see how you might implement similar stuff for > your domain (the code will also be in SVN under examples/server-extension). > > Jim > > PS - It occurs to me though, that if 3rd party plugins become very popular, > we could over time bring them into core and take some responsibility for > them. Perhaps. > > _______________________________________________ > Neo4j mailing list > User@lists.neo4j.org > https://lists.neo4j.org/mailman/listinfo/user > -- Christopher twitter: @fakod blog: http://blog.fakod.eu _______________________________________________ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
