Wow! No wonder no-one replied to this. It was a post with real weight :-) Anyway, I personally like what I'm hearing. Everything sounds good on first read. But I can't help suspecting that things are not as simpleI think we should as that. For example, I suspect that your ideas of enabling versioning in the rest API allow for multiple versions running as separate versions on the same database, in different contexts? Sounds useful, but does smack a little of 'dll-hell'. Perhaps it is only about knowing where to draw the line.
For the declarative syntax, I'm a DSL fan, and so love the idea. I did this once 12 years ago where the spec was written in word (gasp!), and 'compiled' by a perl script into C, C++ and Java versions of the libraries supporting a binary protocol. It worked great. But in retrospect we found only one version (java) ever got used, and finally the whole thing was shut down and replaced by only the java code. So I guess the moral of the story is let the initial version exist for a little while before building the generalization, so we are sure what we want. I also reviewed Martins book, but only once :-) (and I tend to limit my DSL's to internal DSL's in Ruby) On Sun, Feb 6, 2011 at 10:27 PM, Michael Hunger < [email protected]> wrote: > Hi there, > > this weekend I was away from a computer so I spent some time brainstorming > things. I would be interested in any feedback on those thoughts and would > like to broaden the audience beyond the devteam. > > 1) An idea for versioning the rest API (when using URI based versioning > schemes like /db/data/v1/node): > > We could modularize the server, so that it's components like the REST API, > webadmin, monitoring etc. are deployed just as separate jax-rs plugins in a > web-container (just declare those in the web-xml). > Using the versioned jars of the REST api (i.e. rest-api-1.2.jar, > rest-api-1.3.M01.jar) we could (with a restricted classloader) bind their > jax-rs servlets to the context according to the version URI path (i.e. > /db/data/v1). > Then one could decide which jars to publish at a certain server and so also > declare which versions of the API to support. > > 2) Declarative / Programmatic API documentation (REST API DSL) > > I'm in the progress of finishing the java-rest-driver for the Neo4j server > API. (https://github.com/jexp/neo4j-java-rest-binding). (I you want to try > it out, it works so far as a drop-in replacement for the embedded > GraphDatabaseService). > I'm currently running instances of the imdb app and of the neo4j-spatial > geoserver addon on top of that. > > While working on this driver and also while looking at Max' neography I > noticed that you have the strong coupling to the REST API (in terms of URI's > and request/response formats) and at the same time this dependency is string > based and distributed through the whole driver codebase. (Yes I know that is > a part of the driver design that has to be improved). > > So what I though of was the following, please don't flame me but correct > me/point me to better ways if I'm totally wrong here. > > I'm not very aware of existing was to declaratively describe a REST API in > terms of its URIs and formats (json). > What I think would be very nice is a declarative, type-safe, refactoring > aware way to describe the REST API as it is provided by the Neo4j-Server. > This declarative description (using a nice, compact DSL) could be used to > automate the representation generation in the server and also provide the > correct URI-Patterns for jersey. On the client side I could use this > executable description to either generate a facade that my driver binds to > (and won't compile anymore when the facade is changed due to a changed DSL > description). I could also easily generate a test-harness that frees me of > the need of running a neo4j-rest server as it could use the DSL for > generating appropriate responses to the URI-calls behind the facade. > This description can also be used to generate the Neo4j-REST API > documentation that is currently contained in the wiki and has to be changed > manually for API changes. It would also contain the version of the API it > describes so that multiple versions can be checked/generated/coded against. > > Sorry I'm a bit biased here. Too much DSL stuff in the last years that has > proven very helpful and powerful (and also too many rounds of reviewing > Martins DSL book :) > > WDYT? > > Michael > _______________________________________________ > Neo4j mailing list > [email protected] > https://lists.neo4j.org/mailman/listinfo/user > _______________________________________________ Neo4j mailing list [email protected] https://lists.neo4j.org/mailman/listinfo/user
