Yea, I think the path is fine. I was more wondering what alternatives you tried and not suggesting we do something different. I'm fine with the proposal as is.
On Fri, Jul 17, 2026 at 12:48 PM Daniel Worthington-Bodart via dev < [email protected]> wrote: > 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 graph > > > On 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 > >> > > >> > > >
