cayleygraph/cayley · error

no support for HTTP interface for this query language

Error message

no support for HTTP interface for this query language

What it means

Cayley's v1 HTTP query endpoint supports two execution paths: an in-process HTTPQuery handler registered for the query language, or falling back to running the query through a full session. This error is returned when the loaded query language (the "l" handler) implements neither — it has no HTTPQuery hook and no Session factory, so the server cannot execute the query over HTTP at all. It is a server capability error, not a malformed request: the query language simply is not wired for HTTP serving.

Source

Thrown at internal/http/query.go:101

	}
	select {
	case <-ctx.Done():
		errFunc(w, ctx.Err())
		return
	default:
	}
	h, err := api.GetHandleForRequest(r)
	if err != nil {
		errFunc(w, err)
		return
	}
	if l.HTTPQuery != nil {
		defer r.Body.Close()
		l.HTTPQuery(ctx, h.QuadStore, w, r.Body)
		return
	}
	if l.Session == nil {
		errFunc(w, errors.New("no support for HTTP interface for this query language"))
		return
	}

	par, _ := url.ParseQuery(r.URL.RawQuery)
	limit, _ := strconv.Atoi(par.Get("limit"))
	if limit == 0 {
		limit = 100
	}

	ses := l.Session(h.QuadStore)
	bodyBytes, err := ioutil.ReadAll(r.Body)
	if err != nil {
		errFunc(w, err)
		return
	}
	it, err := ses.Execute(ctx, string(bodyBytes), query.Options{
		Collation: query.JSON,
		Limit:     limit,

View on GitHub (pinned to 81dcd7d73e)

Solutions

  1. Check the URL language segment against the query languages registered in the running binary (default builds support gizmo/gremlin andgraphql); fix the language name if it is a typo.
  2. Rebuild/upgrade to a Cayley build that registers the desired query language's HTTPQuery or Session support.
  3. If you embed Cayley as a library, register the query language with a non-nil Session or HTTPQuery handler before serving.
  4. As a workaround, run the query through a supported language or via the Go API instead of the HTTP endpoint.

Example fix

// before
curl -X POST http://localhost:64210/api/v1/query/mql -d '...'
// after (use a language the server supports)
curl -X POST http://localhost:64210/api/v1/query/gizmo -d 'g.V().All()'
Defensive patterns

Strategy: fallback

Validate before calling

langs := []string{"gizmo", "gremlin", "graphql"} // check against registered languages
if !contains(langs, requestedLang) {
    return fmt.Errorf("query language %q not supported over HTTP", requestedLang)
}

Try / catch

resp, err := http.Post(baseURL+"/api/v1/query/gizmo", "application/json", body)
if err != nil { return err }
if resp.StatusCode == http.StatusBadRequest {
    // fall back to a supported language or the Go API
}

Prevention

When it happens

Trigger: POSTing a query to /api/v1/query/<lang> where <lang> resolves to a query.Language implementation whose HTTPQuery is nil and whose Session is nil. Typical cases: requesting a query language that was not registered/compiled into the server binary, or a language that only supports programmatic execution and has no HTTP path.

Common situations: Running a custom or minimal Cayley build where only some query languages (e.g. Gizmo, GraphQL) are registered but the client requests another; typos in the language name in the URL path; older/newer builds where a language lost HTTP support; embedding Cayley with a custom QuadStore that registers no HTTP query handler.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors

AI-assisted analysis of cayleygraph/cayley@81dcd7d73e (2026-09-06). Data as JSON: /api/errors/b539007a23773804. Report an issue: GitHub.