liveBook · Manning

CRUD

As explained in Rust Servers, Services, and Apps

CRUD is the set of create, read, update, and delete operations commonly provided for a resource.

CRUD names the four operations a data-focused application commonly exposes: creating, reading, updating, and deleting records. In a Rust server-side web application, these operations connect web forms or API routes to handlers, database access, models, and tests. section 7.0 section 6.4

A complete CRUD feature typically provides:

  • Create routes and handlers that validate submitted data and persist new records. section 6.4
  • Read routes for collections and individual records, backed by database queries. section 4.4.3
  • Update and delete operations, commonly paired with separate input structures, optional fields, and automated success and error tests. section 6.4

Course CRUD API

A course service exposes collection and detail endpoints. A GET request to /courses/1 returns one course, while a POST request to /courses/ creates a course with tutor_id, course_id, and course_name, persists it, and returns the stored record. The implementation uses Actix Web, PostgreSQL access through sqlx, separated route, handler, model, and database modules, and cargo test for automated checks. The demonstrated iteration emphasizes successful create and read flows; error handling and authentication follow afterward. section 4.4.3 section 6.4

Listing 4.10 The main() function for iteration 3
use actix_web::{web, App, HttpServer};
use dotenv::dotenv;
use sqlx::postgres::PgPool;
use std::env;
use std::io;
use std::sync::Mutex;
 
#[path = "../iter3/db_access.rs"]
mod db_access;
#[path = "../iter3/handlers.rs"]
mod handlers;
#[path = "../iter3/models.rs"]
mod models;
#[path = "../iter3/routes.rs"]
mod routes;
#[path = "../iter3/state.rs"]
mod state;
 
use routes::*;
use state::AppState;
 
#[actix_rt::main]
async fn main() -> io::Result<()> {
   dotenv().ok();
 
   let database_url = env::var("DATABASE_URL").expect(
   "DATABASE_URL is not set in .env file");
   let db_pool = PgPool::connect(&database_url).await.unwrap();
 
   let shared_data = web::Data::new(AppState {                      #1
       health_check_response: "I'm good. You've already
       asked me ".to_string(),
       visit_count: Mutex::new(0),
       db: db_pool,
   });
 
   let app = move || {                                              #2
       App::new()
           .app_data(shared_data.clone())                           #3
           .configure(general_routes)                               #4
           .configure(course_routes)                                #4
   };
 
   //Start HTTP server
 
   HttpServer::new(app).bind("127.0.0.1:3000")?.run().await         #5
}

The application entry point shows how shared state, database connectivity, and separated route, handler, model, and state modules are assembled for a database-backed API. section 4.4.3

How Rust Servers, Services, and Apps covers it

How deep it goes
Builds handlers, routes, database access, models, and tests, while deferring detailed error handling and authentication.
Examples
Uses tutor and course APIs, PostgreSQL records, curl requests, browser routes, module layouts, and cargo test output.
What it assumes
Assumes familiarity with RESTful web services before adding database persistence and CRUD application flows.
What you can do after
Builds CRUD APIs with Actix Web, database persistence, separated modules, and automated tests.
How it connects
Connects RESTful web services, database persistence, web forms, Actix Web, handlers, data models, and automated testing.

Also explained in

Compare how 11 books explain CRUD →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Rust Servers, Services, and Apps. The section links point to the parts of the book it draws on.