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 User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
