Module http
Expand description
Fusee’s HTTP API: /v1, JSON, server-sent events for run changes and
streams, an OpenAPI document, Prometheus metrics, and the web UI.
Every route turns into one of the protocol’s calls, answered by
whatever Calls it serves: a Rust [Engine], a Relay to an SDK’s
engine (engine.serve() in TypeScript and Python), or a server
(fusee server --http). It runs on its own task and reads what the
engine’s existing entry points answer: nothing rides the step path.
let server = fusee::http::serve(engine, "127.0.0.1:7601", fusee::http::HttpOptions::default()).await?;
println!("UI at {}", server.url());| Route | Call |
|---|---|
GET /v1/runs?type=&status=&limit=&where=JSON | list |
POST /v1/runs {type, id, input, idPolicy, timeout, version} | start |
GET /v1/runs/{id} | describe |
GET /v1/runs/{id}/result | result, as {status, value} or {status, error} |
POST /v1/runs/{id}/signals/{name} (body: the value) | signal |
POST /v1/runs/{id}/queries/{name} (body: the argument) | query |
POST /v1/runs/{id}/updates/{name}?id= (body: the argument) | update |
POST /v1/runs/{id}/cancel, /terminate {reason} | cancel, terminate |
POST /v1/runs/{id}/reset {beforeStep, reapplySignals} | reset |
POST /v1/runs/{id}/retry | reset before the failed step |
POST /v1/runs/{id}/resume | resume: a paused run’s step runs again |
GET /v1/runs/{id}/streams/{name}?from=&wait= | streamRead; Accept: text/event-stream follows it |
POST /v1/complete/{token} (body: the value), POST /v1/fail/{token} (body: a failure) | complete, fail |
GET /v1/objects/{type}/{key} | describe and the state query |
POST /v1/objects/{type}/{key}/calls/{handler}?id= (body: the argument) | a call |
PUT, DELETE /v1/objects/{type}/{key}/state/{field}; PATCH (a JSON Patch), POST (an edit), DELETE /v1/objects/{type}/{key}/state; If-Match | editState |
GET /v1/schedules, GET /v1/schedules/{name} | list, the schedule’s describe query |
POST /v1/schedules/{name}/pause, /resume, /trigger; DELETE /v1/schedules/{name} | control signals |
GET /v1/types | types |
GET /v1/limits | limits |
GET /v1/metrics, GET /metrics (Prometheus) | metrics |
GET /v1/info | info |
GET /v1/events | run changes, as server-sent events |
POST /v1/call/{method} (body: the arguments) | any call, for clients without an SDK |
GET /v1/openapi.json | this API |
GET / and /assets/... | the web UI |
Security. It listens on loopback unless told otherwise, and then
requires a token (Authorization: Bearer ...). A request that changes
something must say so in a way a cross-site page cannot forge: a JSON
body (Content-Type: application/json) or X-Fusee-Action: 1; and a
browser Origin must match the host. Without a token, a loopback API
answers only requests that name this machine (localhost, a loopback
address, or its public URL’s host), against DNS rebinding.
Re-exports§
pub use calls::Calls;pub use calls::Relay;pub use calls::RelayedCall;pub use calls::answer;pub use calls::decode_answer;pub use calls::error_json;pub use calls::run_call;
Modules§
- calls
- The call protocol every tool speaks: a method name and JSON arguments,
answered with a JSON value or an error. Server mode relays these calls
to the worker that holds a run’s shard; the HTTP API turns its routes
into them; an SDK’s engine answers them on its own thread through a
Relay.
Structs§
- Codec
Options - How
serve_codecserves. - Http
Client - Calls an engine or server through its HTTP API.
- Http
Options - How the API serves.
- Http
Server - A running API server.
Functions§
- encode_
segment - Percent-encoding of one path segment.
- prometheus
- Prometheus text of per-shard counters.
- prometheus_
json - Prometheus text from a
metricsanswer ({ shards: [...] }). - serve
- Binds
addrand servescallson a task of the current runtime. - serve_
codec - Serves a codec endpoint for the UI:
POST /decodewith{"payloads": [base64, ...]}answers{"payloads": [base64 | null, ...]}, each payload passed throughcodec.decode(null for one it cannot decode). Point the API’sHttpOptions::codec_urlat it. The UI’s browser calls it directly, so the keys and the decoded payloads stay with whoever runs it. - serve_
on - Serves on a listener the caller bound.
- serve_
thread - Serves on a thread of its own, with its own runtime: for engines whose host has no Tokio runtime (the SDKs).