I've also been building my management API around this same concept, so I
can send DELETE /gremlin/{g} to delete that graph, PUT and GET might even
allow bulk import and export of the whole graphOn Fri, 17 Jul 2026 at 20:44, Daniel Worthington-Bodart <[email protected]> wrote: > Thanks for the quick reply! > > On header vs. path: I did consider the header, and it'd work fine. I lean > toward the path because the graph really is a resource here, not just > routing metadata. POST /gremlin/{g} reads as "run this query against this > graph," with the graph as a first-class addressable thing — idiomatically > RESTful rather than using HTTP as a tunnel. > > The practical payoff of that framing: the graph identity shows up where > HTTP infrastructure already looks — cache keys, access logs, CDN path rules > — without parsing the body or knowing a custom header. > > Not an either/or hill to die on; a header's a reasonable middle ground. > But if we're picking a default, my vote's the path. > > On Fri, 17 Jul 2026 at 18:16, Ken Hu <[email protected]> wrote: > >> I think this is probably fine since it's an addition and we aren't going >> to >> remove the "g" field from the request. Currently, TinkerPop doesn't really >> have a notion of server topology and the expectation is that all servers >> can service requests for any "g". That's kind of the reason it works this >> way, but if you are building a server that needs this functionality then >> I'm for making this change. Were there any alternatives you considered? >> E.g. why not just move "g" from body to header rather than having it as >> part of the URL? >> >> On Fri, Jul 17, 2026 at 4:35 AM Daniel Worthington-Bodart via dev < >> [email protected]> wrote: >> >> > Hi all, >> > >> > I've been building a TinkerPop 4 server ( >> > https://github.com/bodar/mogwai-db/) >> > and hit a rough edge in the HTTP protocol I'd like to float. >> > >> > Today a request carries everything in the body — the Gremlin string, >> > bindings, and the traversal-source name (g) that selects the target >> graph — >> > against a single endpoint path. That works end-to-end, but the only >> thing >> > identifying the target graph lives inside the payload. >> > >> > The friction: proxies, gateways, and CDNs route on method + URL + >> headers, >> > never the body. So routing by target graph (multi-tenant sharding, >> > per-graph auth, rate limiting, metrics) means buffering and parsing the >> > body to extract g — a binary parse at the edge with GraphBinary, which >> is >> > exactly what a proxy shouldn't be doing, and in some setups isn't >> possible >> > at all. >> > >> > Proposal: allow the traversal source in the URL path — e.g. POST >> > /gremlin/{g} — as an equivalent to sending g in the body. The body form >> > stays for full backwards compatibility; a path segment simply takes >> > precedence. Ideally the GLVs would default to the path form so the >> > ecosystem becomes proxy-routable out of the box. >> > >> > It's a small, backwards-compatible change that would make TinkerPop >> servers >> > far easier to run behind standard infrastructure. I've implemented the >> path >> > form in my own server and it's been a clear win. >> > >> > Is this something the project would be open to discussing? If there's >> > appetite, I'm happy to create Jira / PR as needed. >> > >> > Thanks, >> > Dan >> > >> >
