Hi @r_moquin ,
Thanks for sharing your experience. This is exactly the type of feedback we need 
Let me explain our thinking: while the RDF endpoint is a convenient component to generate RDF out of data in Neo4j, it's not a great architectural approach to have an HTTP API tightly coupled with the DB. That's essentially the rationale behind the n10s.rdf.export procedures (both spo and cypher). Serialising the triples as records over a neo4j/bolt connection (instead of HTTP) makes it possible for a client application to query neo4j via cypher using the official drivers and therefore being able to work with a cluster, wit aura (neo4j DBaaS) , or in any deployment where direct HTTP to the DB is not an option. The client calls the n10s.rdf.export procedures to get the triples serialised as records and then can reconstitute them for serialisation or process them with a client RDF library (pretty trivial step).
This is exactly what the rdflib-neo4j does if you use python + rdflib.
The idea is to extend this concept to other RDF libraries in other languages (java + rdflib or jena), etc.
I'll share soon a simple example (a handful of lines of python) of how to create an RDF HTTP endpoint detached from the DB following this approach. Watch this space.
What I've described effectively delegates the final serialisation to the client but I hear your suggestion of adding a method that would do it on the server side and return a blob of RDF (basically a long string) instead of a collection of individual triples as records.
Did I interpret your question correctly?
I'm open to this but would like to understand a bit more about your approach. Could you share how the client would use the returned RDF?
Cheers,
JB.