Expand description
Espresso API server with both Axum (HTTP/JSON) and gRPC endpoints
Modules§
- axum 🔒
- Axum HTTP/JSON API handlers
- error
- Typed API errors for proper HTTP/gRPC status code mapping
- proto
- The v2 API contract, generated by
build.rsfrom the proto files inproto/: message types, the tonic server traits, and the protoJSONSerialize/Deserializeimpls that define the HTTP wire encoding. - rest
- Axum REST handlers derived from the
google.api.httpannotations, transcoding HTTP/JSON onto the tonic service traits. - routes
- v1
- V1 API module - legacy APIs
Structs§
- Optional
Modules - Which of the optional API modules to serve, for modes that make them conditional
(mirroring
Options::submit/Options::config/Options::explorer/Options::light_client/Options::hotshot_events).
Constants§
- FILE_
DESCRIPTOR_ SET - The compiled proto descriptor set, for gRPC reflection.
Functions§
- apply_
connection_ 🔒limit - Shared budget: plain requests hold a slot while in flight, streaming sockets for their lifetime; excess gets 429.
- bind_
api 🔒 - Add the reserved top-level routes, apply the optional concurrency limit, rewrite legacy URIs,
and bind/serve the router. Shared by all
serve_axum*entry points. Bind before composing routers: OpenAPI generation takes ~0.5s in debug builds, and clients connecting during it should queue in the accept backlog rather than get refused. - create_
router_ v1 - Create v1 router with OpenAPI documentation.
- merge_
hotshot_ 🔒modules - router_
v2 🔒 - The v2 REST routes exactly as
serve_axummounts them. Extracted so the test asserting every documented route is mounted exercises the same construction; don’t inline it back. - serve_
axum - Start Axum HTTP server with combined v1 and v2 APIs
- serve_
axum_ bare - Serve the bare API (no query or status module): only the HotShot modules are available,
since the only app state is the HotShot handle. State-signature is always on; the rest follow
Options, matchingOptions::init_hotshot_modules. - serve_
axum_ fs - Serve the query API used by the filesystem-backed storage mode: status, availability, node,
token, catchup, and state-signature are always on (tide registered them unconditionally);
submit, config, and hotshot-events follow
Options. Filesystem storage doesn’t implement the reward/merklized-state/explorer/database traits, so those modules aren’t served (a request to one of their routes 404s, matching tide). - serve_
axum_ status - Serve the status-only API: no availability/node/token data source is available, so only
status and the HotShot modules (submit, catchup, state-signature, config, hotshot-events) can
be served. State-signature is always on; the rest follow
Options. - serve_
router 🔒 - serve_
tonic - Start Tonic gRPC server
- url
- Build a full request URL from a server base URL and a path produced by one of the
routes::v1::*builders.