As tempting (and as necessary) as it might be to do transacted "stuff", there are good ways and bad ways to do it. It is important that each REST-ful invocation be thought of as effectively stateless. That said, using an RPC-like approach where you have atomic invocations to:
- Create a unit of work (a.k.a. transaction) and receive back a token, ideally as a URI, that represents that transaction - "POST" additional work to that URI - Commit/Rollback/Terminate that work (and render the URI no longer valid) A great reference is the book by Sam Ruby and Leonard Richardson. While I don't agree with 100% of the model proposed in the book, it definitely helped guide the REST-ful API in our product in a manner that made it very clean to implement, easy to consume, client agnostic, and quite flexible. Rick -----Original Message----- From: user-boun...@lists.neo4j.org [mailto:user-boun...@lists.neo4j.org] On Behalf Of Jim Webber Sent: Tuesday, March 23, 2010 11:39 AM To: Neo user discussions Subject: Re: [Neo] Continuing REST API development Hi Mattias, > - GET / will return URIs for creating nodes and the reference node as > well as the index starting point. Sounds sensible. What about using Atom feeds as the representation for a node set and AtomPub for handling node creation etc? > - To have a browse:able representation in addition to JSON, so that you > can click your way through the graph That would be nice, but... > - Batch operations: to define more than one operation to be performed in > a single transaction ...this would be better :-) > - Security OAuth! I have some ideas about creating an OAuth graph and using that to determine authorisation. > - Transaction control operations (begin, commit, rollback) Gah! Jim _______________________________________________ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user _______________________________________________ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
