Les meilleures crates Rust pour une API en 2026

Ne perds pas une semaine à évaluer 40 crates. Voici la stack backend 2026 tranchée que j’utilise pour chaque API Axum.

Cœur#

• axum 0.8 : router. Extracteurs et middlewares Tower. À associer avec tokio 1.x full. Le câblage complet est détaillé dans le guide API REST Axum + Postgres.
• tokio : runtime. rt-multi-thread, macros, signal (graceful shutdown !), time.
• serde + serde_json : DTOs. #[serde(rename_all="camelCase")] à la frontière API, snake_case à l’intérieur.

Données#

• sqlx 0.9 (runtime-tokio, tls-rustls-ring-webpki, postgres, macros, migrate) : Postgres async avec requêtes vérifiées à la compilation. query! attrape les fautes SQL au build. Attention en migrant depuis 0.8 : la feature runtime-tokio-rustls n’existe plus, le runtime et le TLS se déclarent séparément.
• redis 0.26 / deadpool-redis : cache, rate limit et sessions. Pas de cache dans un HashMap partagé entre instances.
• refinery ou sqlx::migrate! : migrations versionnées, jouées au boot. Jamais de CREATE TABLE à la main en prod.

Plomberie HTTP#

• tower-http : TraceLayer, CorsLayer, CompressionLayer, RequestIdLayer, TimeoutLayer. Il te faut les quatre en prod. Depuis la 0.6, TimeoutLayer::new est déprécié au profit de TimeoutLayer::with_status_code, qui te laisse choisir le code renvoyé au client.
• utoipa + utoipa-swagger-ui : OpenAPI généré depuis le code. Tes équipes front vont t’adorer.
• validator (derive) : #[validate(length, email, range)] sur les DTOs d’entrée. Rejette les données pourries à la frontière.

Observabilité#

• tracing + tracing-subscriber (env-filter, json) : logs structurés. JSON en prod, joli en dev.
• opentelemetry + tracing-opentelemetry : traces vers Jaeger ou Tempo quand les logs ne suffisent plus.
• metrics + metrics-exporter-prometheus : /metrics pour le RPS, les histogrammes de latence et les stats du pool.

Robustesse#

• thiserror + anyhow : thiserror pour les erreurs d’API, anyhow pour les binaires et le démarrage. Un seul AppError mappé vers HTTP, placé dans src/error.rs.
• backon ou tokio-retry : backoff exponentiel pour les appels aval. Pas de boucles de retry à la main.
• reqwest (rustls-tls, json) : HTTP sortant. Mets des timeouts ! Par défaut c’est infini, et c’est un tueur en prod — c’est exactement ce qui plombait ma p99.

Mon extrait Cargo par défaut#

axum = "0.8"
axum-extra = { version = "0.10", features = ["cookie"] }
tokio = { version = "1", features = ["full"] }
serde = { version = "1", features = ["derive"] }
serde_json = "1"
sqlx = { version = "0.9", default-features = false, features = ["runtime-tokio", "tls-rustls-ring-webpki", "postgres", "macros", "migrate", "uuid", "chrono"] }
tower-http = { version = "0.6", features = ["full"] }
tracing = "0.1"
tracing-subscriber = { version = "0.3", features = ["env-filter", "json"] }
thiserror = "2"
anyhow = "1"
validator = { version = "0.20", features = ["derive"] }
utoipa = { version = "5", features = ["axum_extras"] }

Les versions, au 17 septembre 2026#

Relevées sur crates.io le jour de la mise à jour de cet article, et toutes utilisées par le template du site, qui compile en intégration continue. Si tu lis ça dans six mois, vérifie : cargo add <crate> te dira la vérité mieux que moi.

Trois migrations qui cassent, et leur correctif#

Ce sont celles qui m’ont coûté du temps en remontant le template à jour.

SQLx : le runtime et le TLS se déclarent séparément#

La feature runtime-tokio-rustls n’existe plus en 0.9. Un cargo add qui la mentionne échoue avec unrecognized feature.

# Avant (0.8)
sqlx = { version = "0.8", features = ["runtime-tokio-rustls", "postgres"] }

# Après (0.9)
sqlx = { version = "0.9", default-features = false, features = [
  "runtime-tokio", "tls-rustls-ring-webpki", "postgres", "macros", "migrate",
] }

Le default-features = false compte : les features par défaut de SQLx 0.9 incluent any, macros, migrate et json, plus large que nécessaire pour une API qui ne parle qu’à Postgres.

argon2 : le sel se génère tout seul#

En 0.5, il fallait construire un SaltString et le passer au hasher. En 0.6, hash_password prend le mot de passe et rien d’autre : le sel vient de la feature getrandom, active par défaut.

// argon2 0.6
use argon2::password_hash::phc::PasswordHash;
use argon2::{Argon2, PasswordHasher, PasswordVerifier};

let hash = Argon2::default()
    .hash_password(password.as_bytes())?
    .to_string();

Tout exemple qui construit un SaltString::generate(&mut OsRng) est écrit pour la 0.5. Il ne compile plus, et l’erreur (no SaltString in the root) n’oriente pas vers la bonne solution.

tower-http : le timeout choisit son code de retour#

TimeoutLayer::new est déprécié en 0.7 au profit de TimeoutLayer::with_status_code, qui rend explicite ce que reçoit le client quand la requête expire.

.layer(TimeoutLayer::with_status_code(
    StatusCode::REQUEST_TIMEOUT,
    Duration::from_secs(10),
))

Ce que j’évite (pour des API)#

• Les gros ORM magiques : les requêtes SQLx explicites scalent mieux pour du backend
• async-std pour des serveurs en 2026 : Tokio a gagné, l’écosystème suit
• Rouler ta propre auth JWT : prends jsonwebtoken + axum-login ou une auth externalisée (Clerk/Auth0) pour démarrer. Si tu la gères toi-même, suis l’auth JWT dans Axum comme il faut : refresh tokens hashés, rotation, middleware

Tu veux tout ça déjà câblé ? Le template Axum du site utilise exactement ces crates, avec le Dockerfile et les tests. Il compile, la CI le vérifie à chaque commit.