Well, as you said there are number of ways to do it. This post describe a way to do it<http://jcalcote.wordpress.com/2009/08/06/restful-transactions/>, but it's not the post that is the main issue but the comments below it. There is still no consensus about what is the RESTful way of doing tx in RESTful web service.
For sure POST a tx start url and POST for commit (while holding a real database tx) is not a good solution for me. It's not scalable and will block users from even READ depend on my isolation level in the database. I guess it all comes down to how specific my RESTful interface. In my example the current need for tx is to create or delete both node and link, then I might as well create a resource that handle it and work with it. The problem off course is that later on (sooner then I think) I will need to create two links in one tx, and then I will need a new resource for two links and so on. BULK resource are not so likable on RESTful people, but I guess it can work really well for my case. I'll create a BULK change resource, fill it with the changes I want to do and finally change it state to commit which will then and only then start a DB tx, do the changes (maybe check ETag to make sure nothing change in between) and finally commit the tx. That's what I'm thinking about it. Ido On Mon, Dec 20, 2010 at 9:42 PM, Christopher Schmidt < [email protected]> wrote: > 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 <[email protected]> > 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 > > [email protected] > > https://lists.neo4j.org/mailman/listinfo/user > > > > > > -- > Christopher > twitter: @fakod > blog: http://blog.fakod.eu > _______________________________________________ > Neo4j mailing list > [email protected] > https://lists.neo4j.org/mailman/listinfo/user > _______________________________________________ Neo4j mailing list [email protected] https://lists.neo4j.org/mailman/listinfo/user
