Coding Tutorials, Guides & Real Projects
Join us

Building REST APIs with Rust for Backend Development

28 min read
Building REST APIs with Rust for Backend Development

Rust has earned a reputation that is hard to ignore in modern backend engineering. It is fast, memory-safe, and increasingly practical for teams that need reliable APIs without giving up performance or maintainability. For a long time, backend developers were told they had to choose between developer convenience and runtime efficiency. Rust changes that equation. It gives you low-level control without forcing you to accept the kinds of bugs that often creep into systems code. When you build REST APIs with Rust, you are not just writing endpoints that return JSON. You are building software with stronger guarantees, clearer ownership, and a much smaller risk of ugly surprises in production.

What makes Rust especially interesting for API development is not only speed, though speed absolutely matters. It is the way Rust encourages good design from the beginning. The compiler becomes part of your engineering process. It pushes you toward explicit error handling, careful state management, and clean data boundaries. That can feel demanding at first, especially if you come from dynamic languages, but it pays off quickly once your project grows beyond a few endpoints. APIs tend to evolve. Requirements change. Teams expand. Traffic grows. Rust is well suited for that reality because it helps you keep control when the codebase becomes more complex.

In this article, we will build a strong mental model for REST APIs in Rust and walk through the practical pieces that matter in real backend work. We will cover project structure, routing, request and response handling, serialization, validation, database integration, authentication, testing, error management, performance, and deployment. The goal is not just to show code, but to show how to think about Rust as an API platform. By the end, you should feel comfortable starting a Rust-based backend and making it production-ready step by step.

Why Rust for REST APIs?

A REST API usually does a few simple things: accept requests, validate input, apply business rules, talk to storage, and return responses in a predictable format. The challenge is not in the individual steps. The challenge is doing all of them consistently, safely, and at scale. Rust is a strong fit because it handles concurrency very well, it avoids many classes of runtime errors, and it encourages architecture that is easier to reason about over time.

One of Rust’s biggest advantages is predictable performance. In many backend systems, latency spikes are caused by hidden allocation overhead, garbage collection pauses, or thread coordination problems. Rust does not eliminate all performance issues, of course, but it gives you much more visibility into what the program is doing. You can choose lightweight async runtimes, control memory usage carefully, and design endpoints that stay responsive under load. That is especially useful for APIs that serve many concurrent users or handle high-throughput workloads.

Rust is also attractive because of safety. Web APIs often deal with user input, database queries, files, external services, and authentication tokens. Every one of those surfaces is a potential source of bugs. Rust’s type system makes it harder to accidentally mix up data, forget error handling, or dereference invalid memory. In practice, this means fewer crashes and fewer hidden edge cases. The API may still fail, but when it does, it tends to fail in ways you can see and handle intentionally.

Another reason Rust shines in backend development is that the ecosystem has matured enough to support serious API work. Frameworks like Axum and Actix Web make request routing and middleware manageable. Libraries like Serde simplify JSON serialization. SQLx and Diesel help with database access. Tokio gives you a powerful async runtime. Together, these tools let you build a modern API stack without fighting the language.

Choosing a Framework: Axum, Actix Web, or Rocket?

Before writing code, it helps to decide on a framework. Rust has several good web frameworks, and each one has its strengths.

Axum is a popular choice for modern async APIs. It is built on Tokio and Tower, and it tends to feel elegant if you like composable middleware and explicit handler functions. Axum is often a great fit when you want a clean architecture and strong async support.

Actix Web is known for speed and maturity. It has been used in many real production systems and offers a very capable routing and middleware system. Some developers prefer it for its ecosystem and performance. It also has a slightly different style from Axum, so the learning curve may feel different depending on your background.

Rocket offers a pleasant developer experience and expressive syntax. It has improved a lot over the years and can be a good choice when readability and ergonomics matter a lot. It is especially attractive for developers who appreciate a framework that feels concise and friendly.

For this article, we will focus mostly on Axum because it gives us a good balance between modern async architecture and clarity. The concepts we cover will transfer well to other frameworks too.

Setting Up a Rust API Project

Let’s start with a new project. A typical Rust backend uses Cargo, Rust’s package manager and build tool.

cargo new rust_api
cd rust_api

Now add dependencies in Cargo.toml. For a basic REST API with JSON support and async handling, you might begin with something like this:

[package]
name = "rust_api"
version = "0.1.0"
edition = "2021"

[dependencies]
axum = "0.7"
tokio = { version = "1", features = ["full"] }
serde = { version = "1", features = ["derive"] }
serde_json = "1"
tower-http = { version = "0.5", features = ["cors", "trace"] }
tracing = "0.1"
tracing-subscriber = "0.3"

This setup gives you a modern starting point. Axum handles routing and handlers. Tokio powers async execution. Serde handles JSON serialization and deserialization. Tower HTTP adds useful middleware like CORS and request tracing. Tracing helps with observability, which becomes extremely valuable once your API grows.

A simple project structure might look like this:

src/
  main.rs
  app_state.rs
  handlers/
    mod.rs
    health.rs
    users.rs
  models/
    mod.rs
    user.rs
  errors.rs

You do not need to begin with this level of structure if your API is tiny, but it is a healthy pattern for anything that may grow. Separation of concerns matters in Rust because it keeps types, state, and logic easier to manage.

Building the First Endpoint

A basic API often starts with a health check. This endpoint tells you whether the service is alive and reachable. It might seem trivial, but it is useful in container orchestration, load balancers, and deployment checks.

Here is a simple Axum server with a /health endpoint:

use axum::{
    routing::get,
    Json, Router,
};
use serde_json::json;
use tracing_subscriber::{layer::SubscriberExt, util::SubscriberInitExt};

async fn health_check() -> Json<serde_json::Value> {
    Json(json!({
        "status": "ok"
    }))
}

#[tokio::main]
async fn main() {
    tracing_subscriber::registry()
        .with(tracing_subscriber::fmt::layer())
        .init();

    let app = Router::new().route("/health", get(health_check));

    let listener = tokio::net::TcpListener::bind("127.0.0.1:3000")
        .await
        .expect("failed to bind");

    axum::serve(listener, app)
        .await
        .expect("server failed");
}

This code is small, but it already shows several important ideas. The handler returns JSON, routing is explicit, and the server is async. The response format is predictable, which is exactly what clients need. In a larger application, you would add state, error handling, and middleware, but this example is enough to see how Rust API development begins.

Understanding Requests and Responses

In REST API design, most endpoints revolve around a pattern: receive a request body or path parameter, validate it, process it, and return a structured response. Rust makes that pattern very clear. You define types for input and output, and the compiler helps ensure those types stay consistent.

Suppose you want to create a user registration endpoint. A request body might look like this:

{
  "name": "Amina",
  "email": "amina@example.com",
  "password": "secret123"
}

You can model it in Rust like this:

use serde::Deserialize;

#[derive(Debug, Deserialize)]
struct CreateUserRequest {
    name: String,
    email: String,
    password: String,
}

And the response might look like this:

use serde::Serialize;

#[derive(Debug, Serialize)]
struct UserResponse {
    id: i32,
    name: String,
    email: String,
}

When your request and response structures are explicit, your API becomes easier to document and maintain. Clients know what to send, and your handlers know what to return. This is one of Rust’s quiet strengths: the data model is not hidden in loosely structured maps or strings. It is visible in the code.

Creating a User Endpoint

Let’s write a route that accepts JSON and returns a response. For now, we will keep it simple and simulate database insertion.

use axum::{
    extract::Json,
    http::StatusCode,
    response::IntoResponse,
};
use serde::{Deserialize, Serialize};

#[derive(Debug, Deserialize)]
struct CreateUserRequest {
    name: String,
    email: String,
    password: String,
}

#[derive(Debug, Serialize)]
struct UserResponse {
    id: i32,
    name: String,
    email: String,
}

async fn create_user(
    Json(payload): Json<CreateUserRequest>,
) -> impl IntoResponse {
    let user = UserResponse {
        id: 1,
        name: payload.name,
        email: payload.email,
    };

    (StatusCode::CREATED, Json(user))
}

This handler extracts JSON from the request body, creates a response object, and returns HTTP 201 Created. In a real application, you would hash the password, save the user to a database, and handle possible failures. Still, the basic flow is already visible.

The nice thing about Rust here is that request parsing is strongly typed. If the client sends invalid JSON or fields of the wrong type, the framework can reject the request early. That means less manual parsing code and fewer hidden assumptions.

Validation: Do Not Trust Input

No backend article would be complete without validation. A REST API should never assume that incoming data is correct just because it came from a client application. Clients make mistakes, requests get tampered with, and external integrations can fail in strange ways.

You can validate input manually or use a validation crate. Manual validation is often enough for smaller projects and gives you complete control. For example:

fn validate_create_user(req: &CreateUserRequest) -> Result<(), String> {
    if req.name.trim().is_empty() {
        return Err("name cannot be empty".to_string());
    }

    if !req.email.contains('@') {
        return Err("email must be valid".to_string());
    }

    if req.password.len() < 8 {
        return Err("password must be at least 8 characters".to_string());
    }

    Ok(())
}

Then inside your handler:

async fn create_user(
    Json(payload): Json<CreateUserRequest>,
) -> impl IntoResponse {
    if let Err(msg) = validate_create_user(&payload) {
        return (
            StatusCode::BAD_REQUEST,
            Json(serde_json::json!({ "error": msg })),
        );
    }

    let user = UserResponse {
        id: 1,
        name: payload.name,
        email: payload.email,
    };

    (StatusCode::CREATED, Json(user))
}

This may look basic, but it is an important habit. Validation should happen as early as possible, before business logic or database work. That keeps your handlers cleaner and your error messages more predictable.

For more complex applications, you may use libraries like validator to derive validation rules, but manual validation is a perfectly good place to start, especially when you are learning the Rust web stack.

Organizing Application State

Most real APIs need shared state. That state might include a database pool, configuration values, caches, or service clients. Rust handles this elegantly through explicit state management. In Axum, you can attach application state to the router and extract it in handlers.

Here is an example of a simple shared state structure:

use std::sync::Arc;

#[derive(Clone)]
struct AppState {
    app_name: String,
}

impl AppState {
    fn new() -> Self {
        Self {
            app_name: "Rust API".to_string(),
        }
    }
}

Then use it in your router:

use axum::{extract::State, routing::get, Router};

async fn root(State(state): State<Arc<AppState>>) -> String {
    format!("Welcome to {}", state.app_name)
}

#[tokio::main]
async fn main() {
    let state = Arc::new(AppState::new());

    let app = Router::new()
        .route("/", get(root))
        .with_state(state);

    let listener = tokio::net::TcpListener::bind("127.0.0.1:3000")
        .await
        .unwrap();

    axum::serve(listener, app).await.unwrap();
}

This pattern is useful because it is explicit. You know what data is shared, you know where it is injected, and you know that it is thread-safe if wrapped properly. Rust does not let you casually share mutable data without thinking about synchronization. That can feel restrictive at first, but in backend systems it is usually a blessing.

Working with a Database

A REST API almost always needs persistence. You might store users, products, orders, posts, logs, sessions, or analytics events. Rust has good database tooling, and SQLx is a common choice because it offers async support and strong compile-time checking for SQL queries.

Let’s imagine we are using PostgreSQL. Add dependencies:

[dependencies]
sqlx = { version = "0.8", features = ["runtime-tokio", "postgres", "uuid", "chrono"] }
uuid = { version = "1", features = ["v4", "serde"] }
chrono = { version = "0.4", features = ["serde"] }

You might define a user model like this:

use chrono::{DateTime, Utc};
use serde::{Deserialize, Serialize};
use uuid::Uuid;

#[derive(Debug, Serialize, sqlx::FromRow)]
struct User {
    id: Uuid,
    name: String,
    email: String,
    created_at: DateTime<Utc>,
}

#[derive(Debug, Deserialize)]
struct CreateUserRequest {
    name: String,
    email: String,
    password: String,
}

You can create a database pool in your application state:

use sqlx::PgPool;
use std::sync::Arc;

#[derive(Clone)]
struct AppState {
    db: PgPool,
}

Then in your handler, insert a user:

use axum::{
    extract::State,
    http::StatusCode,
    response::IntoResponse,
    Json,
};
use uuid::Uuid;

async fn create_user(
    State(state): State<Arc<AppState>>,
    Json(payload): Json<CreateUserRequest>,
) -> impl IntoResponse {
    if let Err(msg) = validate_create_user(&payload) {
        return (
            StatusCode::BAD_REQUEST,
            Json(serde_json::json!({ "error": msg })),
        );
    }

    let id = Uuid::new_v4();

    let result = sqlx::query!(
        r#"
        INSERT INTO users (id, name, email, password_hash)
        VALUES ($1, $2, $3, $4)
        "#,
        id,
        payload.name,
        payload.email,
        "hashed_password_placeholder"
    )
    .execute(&state.db)
    .await;

    match result {
        Ok(_) => (
            StatusCode::CREATED,
            Json(serde_json::json!({
                "id": id,
                "name": payload.name,
                "email": payload.email
            })),
        ),
        Err(_) => (
            StatusCode::INTERNAL_SERVER_ERROR,
            Json(serde_json::json!({ "error": "failed to create user" })),
        ),
    }
}

A real application would hash the password before insertion and handle database errors more carefully, but the structure is correct. SQLx can help prevent query mismatches, and the async flow fits naturally into Rust’s design.

One of the best things about Rust plus SQLx is that your queries are not hidden behind a lot of ORM magic. You can see the SQL clearly. That is valuable because many backend bugs are really data bugs, and plain SQL is often the best way to keep them understandable.

Error Handling That Feels Intentional

Error handling is one of the places where Rust is both demanding and rewarding. In a web API, you need to translate internal failures into meaningful HTTP responses. That means your code should distinguish between validation errors, authentication failures, not found cases, and real server problems.

A useful pattern is to define an application error type:

use axum::{
    http::StatusCode,
    response::{IntoResponse, Response},
    Json,
};
use serde::Serialize;

#[derive(Debug)]
enum AppError {
    BadRequest(String),
    NotFound(String),
    InternalError,
}

#[derive(Serialize)]
struct ErrorResponse {
    error: String,
}

impl IntoResponse for AppError {
    fn into_response(self) -> Response {
        let (status, message) = match self {
            AppError::BadRequest(msg) => (StatusCode::BAD_REQUEST, msg),
            AppError::NotFound(msg) => (StatusCode::NOT_FOUND, msg),
            AppError::InternalError => (
                StatusCode::INTERNAL_SERVER_ERROR,
                "internal server error".to_string(),
            ),
        };

        (status, Json(ErrorResponse { error: message })).into_response()
    }
}

Then your handlers can return Result<T, AppError>:

async fn get_user() -> Result<Json<serde_json::Value>, AppError> {
    let user_exists = true;

    if !user_exists {
        return Err(AppError::NotFound("user not found".to_string()));
    }

    Ok(Json(serde_json::json!({
        "id": 1,
        "name": "Amina"
    })))
}

This is a very Rust-like way to think about backend failures. Instead of panicking or hiding errors, you model them explicitly and map them cleanly to API responses. That makes your system easier to debug and your client behavior more predictable.

In larger applications, you may use thiserror to create richer error enums and anyhow for higher-level error propagation inside service logic. The important thing is not the specific crate. The important thing is to keep the boundary between internal errors and public HTTP responses well defined.

Designing RESTful Routes

REST design is not just about using GET, POST, PUT, and DELETE. It is about making the API predictable. Clients should be able to guess the shape of your endpoints from the resource names and HTTP methods.

A typical user API might look like this:

  • GET /users to list users

  • GET /users/:id to retrieve a specific user

  • POST /users to create a user

  • PUT /users/:id to replace a user

  • PATCH /users/:id to update part of a user

  • DELETE /users/:id to remove a user

In Axum, these routes are easy to express:

use axum::{
    routing::{delete, get, patch, post, put},
    Router,
};

fn user_routes() -> Router {
    Router::new()
        .route("/users", get(list_users).post(create_user))
        .route("/users/:id", get(get_user).put(update_user).patch(partial_update_user).delete(delete_user))
}

This style keeps route organization clear. Once your API grows, you can break route groups into modules. That is often a good idea because it keeps the main application setup from becoming cluttered.

The real design challenge is not syntax, but consistency. Use plural nouns for resources. Use standard HTTP methods appropriately. Return the right status codes. Keep request and response shapes stable. These choices make your API friendlier to frontend developers and easier to document.

Authentication and Authorization

Most backend APIs need authentication. Some also need authorization. These are not the same thing. Authentication answers the question, “Who are you?” Authorization answers, “What are you allowed to do?”

A common choice for REST APIs is JWT-based authentication. When a user logs in, the server returns a token. The client sends that token on future requests in the Authorization header.

A simplified login handler might look like this:

use axum::{http::StatusCode, Json};
use serde::{Deserialize, Serialize};

#[derive(Debug, Deserialize)]
struct LoginRequest {
    email: String,
    password: String,
}

#[derive(Debug, Serialize)]
struct LoginResponse {
    token: String,
}

async fn login(Json(payload): Json<LoginRequest>) -> impl IntoResponse {
    if payload.email == "amina@example.com" && payload.password == "secret123" {
        let token = "fake-jwt-token";

        (
            StatusCode::OK,
            Json(LoginResponse {
                token: token.to_string(),
            }),
        )
    } else {
        (
            StatusCode::UNAUTHORIZED,
            Json(serde_json::json!({ "error": "invalid credentials" })),
        )
    }
}

Of course, this is only a demonstration. In real systems, you would verify a password hash, generate a signed JWT, set expiration times, and validate the token on protected routes.

A protected route might extract and verify the token before allowing access. In Rust, middleware is a clean way to do that. You can implement reusable authentication logic that intercepts requests and checks headers before the request reaches your handler. That is one of the reasons Rust API frameworks feel powerful once you become comfortable with them.

Authorization rules are usually added after authentication. For example, an admin can delete users, but a regular user cannot. You can model roles explicitly in your database or token claims and then enforce them in your handlers or guards. Keep these rules centralized, because scattering permission checks across many endpoints leads to bugs.

Logging and Observability

A production API should never feel like a black box. When something goes wrong, you need to know what happened, where it happened, and under what conditions. Rust gives you good tools for this through the tracing ecosystem.

You can record request details, latency, and errors. Middleware can automatically log incoming requests and responses. This is incredibly useful in real environments because debugging without logs is just guessing with confidence.

A typical setup might include:

use tracing_subscriber::{layer::SubscriberExt, util::SubscriberInitExt};

fn init_tracing() {
    tracing_subscriber::registry()
        .with(tracing_subscriber::fmt::layer())
        .init();
}

Then inside your handlers:

use tracing::info;

async fn list_users() -> &'static str {
    info!("listing users");
    "users"
}

In practice, you would log more structured information, such as request IDs, user IDs, or database timings. That makes it easier to trace a request from the edge of the system to the storage layer. For distributed systems, that kind of visibility is not optional. It is how you keep the service reliable.

Testing Your API

Testing is where good APIs become trustworthy APIs. Rust has a strong test culture, and backend code benefits a lot from that. You should test input validation, handler behavior, database interaction, and edge cases.

A simple unit test for validation might look like this:

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn rejects_empty_name() {
        let req = CreateUserRequest {
            name: "".to_string(),
            email: "test@example.com".to_string(),
            password: "password123".to_string(),
        };

        let result = validate_create_user(&req);
        assert!(result.is_err());
    }
}

You can also test HTTP routes using Axum’s router and request tools:

#[tokio::test]
async fn health_endpoint_returns_ok() {
    use axum::{body::Body, http::Request};
    use tower::ServiceExt;

    let app = Router::new().route("/health", get(health_check));

    let response = app
        .oneshot(
            Request::builder()
                .uri("/health")
                .body(Body::empty())
                .unwrap(),
        )
        .await
        .unwrap();

    assert_eq!(response.status(), StatusCode::OK);
}

Integration tests are especially valuable when your API talks to a real database. You can spin up a test database, insert fixtures, send requests, and verify the response. That gives you confidence that all the pieces work together, not just in isolation.

A good habit is to test error cases as seriously as success cases. It is easy to make a “happy path” test pass. It is much more important to verify that bad input, missing data, and database failures all produce the correct behavior.

Pagination, Filtering, and Sorting

Sooner or later, most APIs need list endpoints. Returning thousands of rows in one response is rarely a good idea. Pagination keeps responses manageable and makes client-side navigation easier.

A common pattern is to accept query parameters:

use axum::extract::Query;
use serde::Deserialize;

#[derive(Debug, Deserialize)]
struct ListUsersQuery {
    page: Option<u32>,
    limit: Option<u32>,
    search: Option<String>,
}

async fn list_users(
    Query(params): Query<ListUsersQuery>,
) -> impl IntoResponse {
    let page = params.page.unwrap_or(1);
    let limit = params.limit.unwrap_or(10);

    Json(serde_json::json!({
        "page": page,
        "limit": limit,
        "items": []
    }))
}

Pagination is one of those details that seems secondary until your data grows. Then it becomes essential. Filtering and sorting are equally important. A good API lets clients request exactly what they need instead of forcing them to download and process unnecessary data. That reduces latency, improves usability, and keeps resource consumption under control.

When you design these endpoints, be consistent. Use the same query parameter names across resources whenever possible. Decide whether your API uses page-based or cursor-based pagination and stick with it. Cursor-based pagination is often better for large or frequently changing datasets, while page-based pagination is easier for simple interfaces.

Versioning Your API

APIs change. Even when you try to keep them stable, some breaking change will eventually arrive. Maybe you add a required field. Maybe you change an authorization model. Maybe you restructure a response for better clarity. Versioning helps you make those changes without breaking every existing client.

A common pattern is URL versioning:

  • /api/v1/users

  • /api/v2/users

This is straightforward and easy for clients to understand. Another option is header-based versioning, but URL versioning is often simpler in practice.

In Rust, you can organize versioned routes cleanly:

fn api_routes() -> Router {
    Router::new()
        .nest("/api/v1", v1_routes())
        .nest("/api/v2", v2_routes())
}

Versioning is not just a technical detail. It is a promise to your users. It says you care about compatibility and that you will not break them without warning. That matters a lot in professional backend development.

Handling CORS and Middleware

If your API is consumed by a browser-based frontend, you will likely need CORS configuration. Middleware is also useful for request tracing, compression, authentication, and rate limiting.

With Tower HTTP, you can set up CORS like this:

use tower_http::cors::{Any, CorsLayer};

let cors = CorsLayer::new()
    .allow_origin(Any)
    .allow_methods(Any)
    .allow_headers(Any);

Then apply it to your router:

let app = Router::new()
    .route("/health", get(health_check))
    .layer(cors);

For real production systems, you would usually restrict origins rather than allow everything. The principle is simple: keep cross-origin behavior as tight as possible while still supporting legitimate clients.

Middleware is also a good place to enforce request timeouts, add correlation IDs, and apply rate limits. These are not glamorous features, but they make your service much more robust.

Performance Considerations

Rust is fast, but performance is not automatic. You still need to think about database queries, serialization costs, network latency, and contention. The language gives you good tools, but system design still matters.

One performance advantage in Rust is that asynchronous code can handle many concurrent connections efficiently. That does not mean you should make every function async just because you can. Keep the async boundary where it matters: I/O, database calls, external services, and network work. Avoid unnecessary complexity in pure business logic.

Another performance tip is to be careful with cloning. Rust makes ownership explicit, which helps you notice when data is being copied more than necessary. In API handlers, this can matter for large payloads or high-throughput endpoints. Sometimes a clone is fine. Sometimes it is a signal that your design could be improved.

Database access is usually a bigger performance factor than the language itself. Index your tables properly. Avoid N+1 query patterns. Fetch only the columns you need. Cache where it makes sense. Measure before optimizing. Rust helps because it gives you good control, but the real gains come from disciplined backend engineering.

A More Complete Example

Let’s put some of these pieces together in a small, more realistic example. Imagine a users API with health checks, user creation, and user retrieval. The code below is simplified, but it shows the overall structure you might aim for.

use axum::{
    extract::{Path, State},
    http::StatusCode,
    response::IntoResponse,
    routing::{get, post},
    Json, Router,
};
use serde::{Deserialize, Serialize};
use std::sync::Arc;
use tracing::info;
use uuid::Uuid;

#[derive(Clone)]
struct AppState {
    app_name: String,
}

#[derive(Debug, Deserialize)]
struct CreateUserRequest {
    name: String,
    email: String,
    password: String,
}

#[derive(Debug, Serialize)]
struct UserResponse {
    id: Uuid,
    name: String,
    email: String,
}

async fn health_check() -> Json<serde_json::Value> {
    Json(serde_json::json!({ "status": "ok" }))
}

fn validate_create_user(req: &CreateUserRequest) -> Result<(), String> {
    if req.name.trim().is_empty() {
        return Err("name cannot be empty".to_string());
    }
    if !req.email.contains('@') {
        return Err("email must be valid".to_string());
    }
    if req.password.len() < 8 {
        return Err("password must be at least 8 characters".to_string());
    }
    Ok(())
}

async fn create_user(
    State(_state): State<Arc<AppState>>,
    Json(payload): Json<CreateUserRequest>,
) -> impl IntoResponse {
    if let Err(msg) = validate_create_user(&payload) {
        return (
            StatusCode::BAD_REQUEST,
            Json(serde_json::json!({ "error": msg })),
        );
    }

    let user = UserResponse {
        id: Uuid::new_v4(),
        name: payload.name,
        email: payload.email,
    };

    info!("user created");

    (StatusCode::CREATED, Json(user))
}

async fn get_user(Path(id): Path<Uuid>) -> impl IntoResponse {
    let user = UserResponse {
        id,
        name: "Amina".to_string(),
        email: "amina@example.com".to_string(),
    };

    (StatusCode::OK, Json(user))
}

#[tokio::main]
async fn main() {
    tracing_subscriber::fmt::init();

    let state = Arc::new(AppState {
        app_name: "Rust API".to_string(),
    });

    let app = Router::new()
        .route("/health", get(health_check))
        .route("/users", post(create_user))
        .route("/users/:id", get(get_user))
        .with_state(state);

    let listener = tokio::net::TcpListener::bind("127.0.0.1:3000")
        .await
        .unwrap();

    axum::serve(listener, app).await.unwrap();
}

This example is intentionally minimal, but it is already shaped like a real backend. There is state, routing, typed JSON, path extraction, validation, logging, and structured responses. That is the foundation of many REST APIs in Rust.

Deployment Considerations

When it is time to deploy, Rust has a pleasant advantage: binaries are efficient and self-contained. You can often compile a single executable and ship it into a container or server environment. That makes deployment simpler than in ecosystems that need large runtime stacks.

A common production approach is to use multi-stage Docker builds. First, compile the Rust binary in a builder image. Then copy the binary into a small runtime image. That reduces image size and attack surface.

A very basic Dockerfile might look like this:

FROM rust:1.82 as builder
WORKDIR /app
COPY . .
RUN cargo build --release

FROM debian:bookworm-slim
WORKDIR /app
COPY --from=builder /app/target/release/rust_api /usr/local/bin/rust_api
EXPOSE 3000
CMD ["rust_api"]

In real deployments, you will also want environment variables for configuration, logging output to standard out, health checks, and proper secret management. Rust does not change those deployment concerns, but it fits nicely into modern container-based infrastructure.

Common Mistakes to Avoid

Many early Rust API projects run into the same avoidable problems. One mistake is overcomplicating the project too early. Rust can tempt you into building a very elaborate type system from day one. Resist that urge. Start with clear models, simple routes, and practical validation. Elegance comes from restraint, not from making everything abstract.

Another common mistake is ignoring error messages from the compiler and forcing the code to compile without understanding the design issue. Rust’s compiler is not just checking syntax. It is giving you architectural feedback. Learning to read that feedback well will save you a lot of time later.

A third mistake is mixing business logic directly into handlers until the code becomes hard to test. A better pattern is to keep handlers thin and move core logic into service functions or modules. That makes your code easier to test and easier to evolve.

Finally, do not treat security as an afterthought. Hash passwords properly. Validate input. Protect sensitive endpoints. Use secure headers where relevant. Keep secrets out of source control. A Rust backend can be very safe, but only if you design it that way intentionally.

When Rust Is the Right Choice

Rust is not always the fastest language to prototype in, and that is okay. It is especially valuable when correctness, performance, and long-term maintainability matter more than getting the first version out in a weekend. If you are building an internal tool with a tiny audience, another stack may be perfectly fine. But if you expect the API to grow, handle real traffic, or require strong guarantees, Rust becomes an excellent choice.

It is also a strong fit for teams that care about discipline and clarity. Rust encourages explicitness. That can make onboarding a little slower, but it often leads to cleaner systems and fewer hidden assumptions. Once a team gets comfortable with the language, they tend to appreciate the way it keeps them honest.

Final Thoughts

Building REST APIs with Rust for backend development is both practical and deeply rewarding. You get speed, safety, strong typing, and a growing ecosystem that supports real-world production systems. More importantly, Rust helps you write APIs that are easier to trust. That matters when your service is handling customer data, internal workflows, or external integrations that need to be reliable day after day.

The best way to learn Rust for backend work is to build something real. Start with a health check, add a CRUD resource, connect a database, introduce validation, then layer in authentication and testing. Do not try to master everything at once. Let the project teach you. Rust will push you to make decisions carefully, and that discipline will shape you into a stronger backend developer.

Over time, you will notice something interesting: the things Rust asks you to think about upfront are often the same things that save you from pain later. Ownership, lifetimes, error handling, concurrency, and data modeling are not academic concerns in backend work. They are the difference between a service that survives growth and a service that slowly becomes fragile. That is why Rust is not just an interesting language for APIs. It is a serious one.

#Rust REST API #Rust backend development #build API with Rust #Axum tutorial #Actix Web tutorial #Rust web development #REST APIs in Rust #Rust API best practices #Rust JSON API #backend with Rust

Subscribe to our newsletter

12k+

Subscribers

Weekly

Frequency

Free

Always