ferrox_api/lib.rs
1//! The wire contract between `ferrox-server` and everything that talks
2//! to it: the web UI served at `/`, the desktop shell that spawns the
3//! server as a child process, `ferrox chat`, and any third-party client.
4//!
5//! Why a crate instead of literals at both ends: the UI is deliberately
6//! "just another API client" (see `docs/plans/ferrox-ui.md`) -- it calls
7//! the same public endpoints an IDE would, so the public contract cannot
8//! rot without the UI breaking first. That only holds if there is
9//! exactly one definition of each path and each payload shape. A
10//! hand-copied `"/v1/chat/completions"` in a frontend is a contract that
11//! drifts silently; a `pub const` that both sides import is one that
12//! cannot.
13//!
14//! Scope rule: this crate owns *ferrox-specific* additions and control
15//! surfaces (health/capabilities, the process-ready handshake, usage
16//! timings, task progress). The OpenAI-compatible request/response
17//! bodies stay in `ferrox-server` where they are validated -- mirroring
18//! someone else's schema here would create a second place for it to be
19//! wrong.
20//!
21//! Deliberately dependency-light (serde only): a desktop shell, a CLI
22//! and a WASM frontend may all link it.
23
24pub mod admin;
25pub mod cancel;
26pub mod health;
27pub mod lifecycle;
28pub mod progress;
29pub mod request_id;
30pub mod routes;
31pub mod usage;
32
33pub use admin::{
34 CancelResponse, DownloadRequest, LoadModelRequest, ModelEntry, ModelState, ModelsResponse,
35 ProgressState, RecentRequest, StatsResponse, TaskAccepted, TaskKind, TaskProgress, TaskStatus,
36 TaskView, TasksResponse, UnloadResponse,
37};
38pub use cancel::{CancelGenerationRequest, CancelGenerationResponse};
39pub use health::{Capability, HealthResponse, HealthState};
40pub use lifecycle::{ServerReady, READY_EVENT};
41pub use progress::{RateEstimator, RateReport};
42pub use request_id::next_request_id;
43pub use usage::{CompletionTokensDetails, Usage};