HTTP data sources

EXTERNAL_HTTP() lets FeatureQL fetch data from REST APIs, microservices, and any HTTP endpoint. This is useful for integrating third-party services, calling internal microservices, or querying ML model endpoints as part of a feature computation.

Creating an HTTP source

Define a reusable HTTP endpoint with SOURCE_HTTP():

CREATE OR REPLACE FEATURES AS
SELECT
    FM.DEMO1.HTTP_SOURCE1 := SOURCE_HTTP('http://host.docker.internal:8010/hello' WITH (
        query_params=ROW('default1' AS "name"),
        timeout='500ms'
    ))
;

The source captures the base URL, default query parameters, and timeout. These defaults apply to every request unless overridden at call time.

Making requests with EXTERNAL_HTTP()

Use EXTERNAL_HTTP() to call the endpoint with dynamic parameters:

WITH
    FIRSTNAME := INPUT(VARCHAR),
SELECT
    FIRSTNAME := BIND_VALUES(ARRAY['Alice', 'Bob', 'Charlie']),
    HTTP_RESPONSE := EXTERNAL_HTTP(FROM FM.DEMO1.HTTP_SOURCE1 WITH (
        query_params=ROW(FIRSTNAME AS name)
    ))
;

The query_params in the request override the defaults from the source definition. For each input value, FeatureMesh issues a separate HTTP request — FIRSTNAME := 'Alice' becomes GET http://host.docker.internal:8010/hello?name=Alice, and so on.

EXTERNAL_HTTP() always returns a VARCHAR. If the response is JSON, parse it with JSON_PARSE_AS() to get a typed row. If the request fails (timeout, network error, non-200 response), the result is NULL — use COALESCE() to provide a fallback.

Performance considerations

Parallelization: FeatureMesh issues multiple HTTP requests concurrently when a query has several input values.

Timeouts: Set timeouts aggressively. A slow external service should fail fast rather than block the entire feature computation.

No retries: There is no built-in retry policy. If reliability is critical, put a retry-capable proxy or load balancer in front of the target service.

Rate limiting: Be aware of API rate limits on external services. FeatureMesh can generate bursts of concurrent requests.

Network latency: Every HTTP call adds network round-trip time. For latency-sensitive features, prefer Redis or JDBC when possible.

When to use HTTP vs. other connectors

HTTP is the most flexible connector — it can reach anything with a URL. But it's also the slowest due to network overhead and serialization. Use it when:

• The data lives behind an API with no direct database access
• You need to call an external ML model or scoring service
• The source system only exposes a REST interface

For data already in a database, JDBC is faster. For cached or precomputed values, Redis is fastest.