Skip to main content Skills Marketplace Descubra e explore skills de IA criadas pela comunidade.
Ocupações relacionadas SOC
Baseado na classificação ocupacional SOC
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Mostrar detalhes do prompt Um comando direto ignora o prompt de revisão. Verifique a origem antes de executá-lo.
npx skills add https://github.com/bobmatnyc/claude-mpm-skills --skill axumO comando permanece em uma só linha. Role horizontalmente para revisá-lo antes de copiar.
Prefere uma cópia local? Baixe os arquivos disponíveis atualmente no SkillsMP.
Baixar Zip Baixando... Explorador de arquivos
2 arquivos Mais deste repositório LinkedIn automation via the Linked API CLI - fetch profiles, search people and companies, send messages, manage connections, create posts, react, comment, and run Sales Navigator and custom workflows. Use when the user wants to interact with LinkedIn.
Xquik X data automation API - Use REST or MCP for tweet search, user lookup, follower exports, media downloads, monitors, webhooks, giveaway draws, and confirmation-gated X actions.
MCP (Model Context Protocol) - Build AI-native servers with tools, resources, and prompts. TypeScript/Python SDKs for Claude Desktop integration.
name axum description Axum (Rust) web framework patterns for production APIs: routers/extractors, state, middleware, error handling, tracing, graceful shutdown, and testing user-invocable false disable-model-invocation true version 1.1.1 category toolchain author Claude MPM Team license MIT progressive_disclosure {"entry_point":{"summary":"Build production Rust APIs with Axum using typed extractors, Tower middleware, structured errors, tracing, and testable routers","when_to_use":"When building Rust HTTP APIs/services that need predictable middleware composition, strong typing, and production-ready shutdown/observability patterns","quick_start":"1. Add axum + tokio + tower-http 2. Build Router with typed handlers 3. Define AppState + error type 4. Add tracing + timeouts 5. Test router with ServiceExt"},"token_estimate":{"entry":140,"full":5500}} context_limit 800 tags ["rust","axum","tokio","http","api","tower","middleware","tracing"] requires_tools []
Axum (Rust) - Production Web APIs
Overview
Axum is a Rust web framework built on Hyper and Tower. Use it for type-safe request handling with composable middleware, structured errors, and excellent testability.
Quick Start
Minimal server
✅ Correct: typed handler + JSON response
use axum::{routing::get, Json, Router};
use serde::Serialize;
use std::net::SocketAddr;
#[derive(Serialize)]
struct Health {
status: &'static str ,
}
async fn health () -> Json<Health> {
Json (Health { status: "ok" })
}
#[tokio::main]
async fn main () {
let app = Router::new ().route ("/health" , get (health));
let addr : SocketAddr = "0.0.0.0:3000" .parse ().unwrap ();
let listener = tokio::net::TcpListener::bind (addr).await .unwrap ();
axum::serve (listener, app).await .unwrap ();
}
❌ Wrong: block the async runtime
async fn handler () {
std::thread::sleep
from_secs
1
Core Concepts
Router + handlers Handlers are async functions that return something implementing IntoResponse.
use axum::{routing::get, Router};
fn router () -> Router {
let api = Router::new ()
.route ("/users" , get (list_users))
.route ("/users/:id" , get (get_user));
Router::new ().nest ("/api/v1" , api)
}
async fn list_users () -> &'static str { "[]" }
async fn get_user () -> &'static str { "{}" }
Extractors Prefer extractors for parsing and validation at the boundary:
Path<T>: typed path paramsQuery<T>: query stringsJson<T>: JSON bodiesState<T>: shared application state ✅ Correct: typed path + JSON
use axum::{extract::Path, Json};
use serde::{Deserialize, Serialize};
#[derive(Deserialize)]
struct CreateUser {
email: String ,
}
#[derive(Serialize)]
struct User {
id: String ,
email: String ,
}
async fn create_user (Json (body): Json<CreateUser>) -> Json<User> {
Json (User { id: "1" .into (), email: body.email })
}
async fn get_user (Path (id): Path<String >) -> Json<User> {
Json (User { id, email: "a@example.com" .into () })
}
Dependencies & Crate Structure If your crate is published as a library in addition to being built as a binary, isolate the HTTP stack to avoid bloating library consumers.
✅ Correct: optional HTTP feature
[dependencies]
axum = { version = "0.7" , optional = true }
tower-http = { version = "0.5" , optional = true }
tokio = { version = "1" , features = ["full" ] }
[features]
default = ["http-server" ]
http-server = ["axum" , "tower-http" ]
[[bin]]
name = "my-service"
required-features = ["http-server" ]
Library consumers (cargo add my-lib) get just the core logic without the HTTP overhead.
Binary builds include the server by default: cargo install my-crate works as expected.
Opt-out is explicit: cargo add my-crate --no-default-features for library use.
❌ Wrong: unconditional HTTP dependencies
axum = "0.7"
tower-http = "0.5"
Production Patterns
1) Shared state (DB pool, config, clients) Use State<Arc<AppState>> and keep state immutable where possible.
✅ Correct: AppState via Arc
use axum::{extract::State, routing::get, Router};
use std::sync::Arc;
#[derive(Clone)]
struct AppState {
build_sha: &'static str ,
}
async fn version (State (state): State<Arc<AppState>>) -> String {
state.build_sha.to_string ()
}
fn app (state: Arc<AppState>) -> Router {
Router::new ().route ("/version" , get (version)).with_state (state)
}
2) Structured error handling (IntoResponse) Centralize error mapping to HTTP status codes and JSON.
✅ Correct: AppError converts into response
use axum::{http::StatusCode, response::IntoResponse, Json};
use serde::Serialize;
#[derive(Debug)]
enum AppError {
NotFound,
BadRequest (&'static str ),
Internal,
}
#[derive(Serialize)]
struct ErrorBody {
error: &'static str ,
}
impl IntoResponse for AppError {
fn into_response (self ) -> axum::response::Response {
let (status, msg) = match self {
AppError::NotFound => (StatusCode::NOT_FOUND, "not_found" ),
AppError::BadRequest (_) => (StatusCode::BAD_REQUEST, "bad_request" ),
AppError::Internal => (StatusCode::INTERNAL_SERVER_ERROR, "internal" ),
};
(status, Json (ErrorBody { error: msg })).into_response ()
}
}
3) Middleware (Tower layers) Use tower-http for production-grade layers: tracing, timeouts, request IDs, CORS.
✅ Correct: trace + timeout + CORS
use axum::{routing::get, Router};
use std::time::Duration;
use tower::ServiceBuilder;
use tower_http::{
cors::{Any, CorsLayer},
timeout::TimeoutLayer,
trace::TraceLayer,
};
fn app () -> Router {
let layers = ServiceBuilder::new ()
.layer (TraceLayer::new_for_http ())
.layer (TimeoutLayer::new (Duration::from_secs (10 )))
.layer (CorsLayer::new ().allow_origin (Any));
Router::new ()
.route ("/health" , get (|| async { "ok" }))
.layer (layers)
}
4) Graceful shutdown Terminate on SIGINT/SIGTERM and let in-flight requests drain.
✅ Correct: with_graceful_shutdown
async fn shutdown_signal () {
let ctrl_c = async {
tokio::signal::ctrl_c ().await .ok ();
};
#[cfg(unix)]
let terminate = async {
tokio::signal::unix::signal (tokio::signal::unix::SignalKind::terminate ())
.ok ()
.and_then (|mut s| s.recv ().await );
};
#[cfg(not(unix))]
let terminate = std::future::pending::<()>();
tokio::select! {
_ = ctrl_c => {}
_ = terminate => {}
}
}
#[tokio::main]
async fn main () {
let app = app ();
let listener = tokio::net::TcpListener::bind ("0.0.0.0:3000" ).await .unwrap ();
axum::serve (listener, app)
.with_graceful_shutdown (shutdown_signal ())
.await
.unwrap ();
}
Ops: Graceful Shutdown in Supervised Environments Signal handling above is application-level. In production, your supervisor (systemd, launchd, container orchestrator) controls the actual termination window.
systemd (Linux) : Set KillSignal=SIGTERM and TimeoutStopSec=120 (or higher) in your .service file.
The default 90s timeout can fire mid-fsync on networked storage (EBS/EFS), truncating writes.
120s gives in-flight HTTP requests time to drain plus a safety margin for filesystem syncs.
launchd (macOS) : Use launchctl bootout (sends SIGTERM and waits) instead of launchctl kickstart -k (SIGKILL, truncates in-flight I/O).
Client-side reconnection : Have HTTP clients and MCP bridges connecting to the service implement exponential backoff (starting 200ms, capped at 30s) so brief restarts are transparent and don't cascade errors upstream.
Testing Test routers without sockets using tower::ServiceExt.
✅ Correct: request/response test
use axum::{body::Body, http::Request, Router};
use tower::ServiceExt;
#[tokio::test]
async fn health_returns_ok () {
let app : Router = super::app ();
let res = app
.oneshot (Request::builder ().uri ("/health" ).body (Body::empty ()).unwrap ())
.await
.unwrap ();
assert_eq! (res.status (), 200 );
}
Decision Trees
Axum vs other Rust frameworks
Prefer Axum for Tower middleware composition and typed extractors.
Prefer Actix Web for a mature ecosystem and actor-style runtime model.
Prefer Warp for functional filters and minimalism.
Anti-Patterns
Block the async runtime (std::thread::sleep, blocking I/O inside handlers).
Use unwrap() in request paths; return structured errors instead.
Run without timeouts; add request timeouts and upstream deadlines.
Resources 