Rust API

You are a Rust backend developer. The user wants to scaffold a production-ready web API using either Actix-web or Axum framework.

What to check first

• Run rustc --version to verify Rust 1.70+ is installed
• Run cargo --version to confirm Cargo is available
• Decide between Actix-web (mature, high-performance) or Axum (modern, tokio-based, trait-object free)

Steps

1. Create a new Cargo project with cargo new my_api --bin
2. Add dependencies to Cargo.toml: choose actix-web = "4" OR axum = "0.7", plus tokio = { version = "1", features = ["full"] } and serde = { version = "1", features = ["derive"] }
3. For Actix: set up #[actix_web::main] macro in main.rs; for Axum: use #[tokio::main]
4. Define request/response structs using #[derive(Serialize, Deserialize)] from serde
5. Create handler functions with correct signatures: Actix uses HttpRequest + web::Json<T> parameters; Axum uses Json<T> extractors and async return types
6. Define routes using web::scope() in Actix or Router::new().route() builder in Axum
7. Configure middleware for logging: middleware::Logger in Actix, TraceLayer in Axum with tower_http
8. Bind to address and start server: HttpServer::new() for Actix or axum::Server::bind() for Axum

Code

// Axum example (modern approach)
use axum::{
    extract::{Json, Path},
    http::StatusCode,
    routing::{get, post},
    Router,
};
use serde::{Deserialize, Serialize};
use std::sync::Arc;
use tokio::sync::Mutex;

#[derive(Serialize, Deserialize, Clone, Debug)]
struct Item {
    id: u32,
    name: String,
    description: String,
}

#[derive(Serialize, Deserialize)]
struct CreateItemRequest {
    name: String,
    description: String,
}

type ItemStore = Arc<Mutex<Vec<Item>>>;

#[tokio::main]
async fn main() {
    let store: ItemStore = Arc::new(Mutex::new(vec![]));

    let app = Router::new()
        .route("/items", post(create_item).get(list_items))
        .route("/items/:id", get(get_item).delete(delete_item))
        .route("/health", get(health_check))
        .with_state(store);

    let listener = tokio::net::T

Note: this example was truncated in the source. See the GitHub repo for the latest full version.

Common Pitfalls

• Treating this skill as a one-shot solution — most workflows need iteration and verification
• Skipping the verification steps — you don't know it worked until you measure
• Applying this skill without understanding the underlying problem — read the related docs first

When NOT to Use This Skill

• When a simpler manual approach would take less than 10 minutes
• On critical production systems without testing in staging first
• When you don't have permission or authorization to make these changes

How to Verify It Worked

• Run the verification steps documented above
• Compare the output against your expected baseline
• Check logs for any warnings or errors — silent failures are the worst kind

Production Considerations

• Test in staging before deploying to production
• Have a rollback plan — every change should be reversible
• Monitor the affected systems for at least 24 hours after the change