はい、承知いたしました。RustによるモダンWeb開発フレームワークであるactix-webに関する詳細なガイド記事を記述します。約5000語を目指し、主要な概念、使い方、実践的な側面を網羅します。

actix web ガイド：RustによるモダンWeb開発の実践

はじめに：RustとWeb開発の新たな地平

近年、Webアプリケーション開発の世界は、サーバーサイドからフロントエンドに至るまで、急速な変化を遂げています。特にパフォーマンス、安全性、並行処理の効率が求められる領域では、従来の言語やフレームワークの限界が見え始めています。そこで注目を集めているのが、システムプログラミング言語として設計されたRustです。

Rustはその厳格な所有権システムにより、メモリ安全性とスレッド安全性を保証し、同時にC++に匹敵するランタイム性能を実現します。ガベージコレクションがないため、予測可能なパフォーマンスを提供し、低レイテンシなサービス構築に適しています。これらの特性は、特に高負荷なWebサービスやAPI開発において、大きなアドバンテージとなります。

Rustのエコシステムはまだ比較的新しいものの、急速に成熟しており、Web開発のための優れたライブラリやフレームワークが登場しています。その中でも、特に高いパフォーマンスと堅牢性で評価されているのがactix-webです。

actix-webは、アクターモデルに基づいた非同期Webフレームワークであり、Rustの非同期ランタイムであるtokio（またはかつてのactix-rt）上で動作します。その設計思想は、非同期処理を効率的に扱い、高い並行性を実現することにあります。ベンチマークでも常にトップクラスの性能を示しており、プロダクション環境での利用も増えています。

このガイド記事では、Rustを使ったモダンなWeb開発をactix-webを通して実践する方法を、初心者からある程度の経験者まで理解できるよう、詳細に解説していきます。基本的なアプリケーション構造から、ルーティング、リクエスト/レスポンス処理、状態管理、ミドルウェア、エラーハンドリング、テストに至るまで、actix-webを使ったWeb開発に必要な知識を網羅的にカバーします。

さあ、Rustとactix-webの世界へ飛び込み、安全で高速なWebアプリケーション開発を始めましょう。

第1章：Rust開発環境のセットアップ

actix-webを使った開発を始める前に、まずはRustの開発環境を整える必要があります。

1.1 Rustのインストール

Rustのインストールは、公式が提供するrustupというツールを使うのが最も一般的で推奨される方法です。rustupは、Rustコンパイラ（rustc）、ビルドツール/パッケージマネージャー（cargo）、ドキュメンテーションなど、Rust開発に必要なツール群の管理を行います。

macOSまたはLinuxの場合、ターミナルを開き、以下のコマンドを実行します。

bash
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

Windowsの場合、公式ウェブサイト（https://www.rust-lang.org/tools/install）からインストーラをダウンロードして実行します。

インストールが完了したら、新しいターミナルセッションを開くか、現在のセッションで環境変数を再読み込みします（シェルの指示に従ってください）。

インストールが成功したか確認するために、以下のコマンドを実行します。

bash
rustc --version
cargo --version

それぞれのバージョン情報が表示されれば成功です。

1.2 新しいプロジェクトの作成

Rustプロジェクトはcargoを使って管理します。新しいactix-webプロジェクトを作成するには、以下のコマンドを実行します。

bash
cargo new my-actix-app --bin

これにより、my-actix-appというディレクトリが作成され、その中に基本的なRustプロジェクトのファイル構造（Cargo.tomlとsrc/main.rs）が生成されます。--binフラグは実行可能バイナリプロジェクトを作成することを示します（デフォルトでバイナリですが、明示的に指定しても良いでしょう）。

1.3 actix-webの依存関係を追加

プロジェクトの依存関係はCargo.tomlファイルで管理します。actix-webとその非同期ランタイム（通常はtokioが推奨されますが、actix-web 4以降はtokioがデフォルトです）を追加します。

my-actix-app/Cargo.tomlを開き、[dependencies]セクションに以下を追加します。

“`toml
[dependencies]
actix-web = “4” # 最新のバージョンを指定することが推奨されます
actix-rt = “2” # actix-web 4系では actix-rt を明示的に指定する必要がある場合があります (tokio がデフォルト)

非同期ランタイムとして tokio を直接指定することも可能です。

tokio = { version = “1”, features = [“full”] }

“`

補足: actix-web 4.x系では、内部的にtokioがデフォルトの非同期ランタイムとして使用されます。actix-rtクレートは、特にactix固有のランタイム機能が必要な場合や、古いバージョンからの移行で使用されることがありますが、多くの場合はactix-webの依存関係だけで十分です。tokio = { version = "1", features = ["full"] }のようにtokioを明示的に追加するのは、tokioの他の機能（タイマー、シグナルなど）をアプリケーション内で直接利用する場合です。このガイドでは、特に明記しない限り、actix-webの依存関係のみで進めます。

依存関係を追加したら、cargo buildまたはcargo runを実行すると、Cargoが自動的に依存クレートをダウンロードしてビルドします。

これで、actix-webを使ったWebアプリケーション開発を始める準備が整いました。

第2章：actix-webアプリケーションの基本構造

actix-webアプリケーションは、主に以下の要素で構成されます。

1. 非同期ランタイム: アプリケーションの実行を担う非同期コンテキスト（actix-web 4.xではTokioがデフォルト）。
2. HttpServer: HTTPサーバー自体を起動し、リクエストを待ち受けます。
3. App: アプリケーションの定義を行います。ルーティング、ミドルウェア、アプリケーション全体の状態などがここで設定されます。
4. ハンドラー関数: 特定のURLパスとHTTPメソッドに対応する処理を記述した非同期関数。リクエストを受け取り、レスポンスを生成します。

これらの要素を使って、簡単な「Hello, world!」アプリケーションを作成してみましょう。

src/main.rsファイルを以下の内容で置き換えます。

“`rust
use actix_web::{get, App, HttpServer, Responder};

// #[get(“/”)] 属性マクロは、GETメソッドのルート “/” にこの関数を紐付けます。
// 非同期関数として定義し、Responderトレイトを実装した型を返します。

[get(“/”)]

async fn index() -> impl Responder {
“Hello, world!” // &str は Responder を実装しています
}

// main関数は actix_web アプリケーションのエントリーポイントです。
// #[actix_web::main] 属性マクロは、非同期main関数を定義するための糖衣構文です。
// これにより、actix-web 実行に必要な非同期ランタイムの設定が行われます。

[actix_web::main]

async fn main() -> std::io::Result<()> {
// HttpServer::new() で新しいサーバーインスタンスを作成します。
// .app() メソッドで、アプリケーションの定義 (App) を渡します。
// App::new() で新しいアプリケーションインスタンスを作成します。
// .service() メソッドで、定義したハンドラー関数 (ここでは index 関数) をサービスとして追加します。
HttpServer::new(|| {
App::new()
.service(index) // index 関数をルートハンドラーとして登録
})
// .bind() メソッドで、サーバーがリッスンするIPアドレスとポートを指定します。
.bind((“127.0.0.1”, 8080))?
// .run() メソッドで、サーバーを起動し、リクエストの処理を開始します。
// このメソッドはサーバーがシャットダウンされるまでブロックします。
.run()
.await
}
“`

このコードについて解説します。

• use actix_web::...;: actix-webクレートから必要な要素をインポートしています。getはGETメソッドのルート定義に使う属性マクロ、Appはアプリケーション定義、HttpServerはHTTPサーバー、Responderはレスポンスとして返せる型が実装すべきトレイトです。
• #[get("/")]: これはRustの属性マクロです。その下の関数を、HTTP GETメソッドでパス/に対するリクエストを処理するハンドラーとしてactix-webに登録するように指示します。
• async fn index() -> impl Responder: ハンドラー関数は非同期関数である必要があります。async fnとして定義し、awaitキーワードを使って非同期処理を待つことができます（この簡単な例では使っていませんが）。戻り値の型はimpl Responderとしています。これは、Responderトレイトを実装している任意の型を返すことができることを意味します。"Hello, world!"という文字列リテラルはResponderを実装しているため、これをそのまま返すことができます。
• #[actix_web::main]: actix-webが提供する属性マクロで、非同期のmain関数を書くためのボイラープレートコードを生成してくれます。内部的には、非同期ランタイムを起動し、その中でmain関数を実行するように設定します。
• HttpServer::new(|| { ... }): 新しいHttpServerインスタンスを作成します。引数にはクロージャを取ります。このクロージャは新しいリクエストが来るたびに（実際にはワーカープロセスごとに一度）、新しいAppインスタンスを生成するために実行されます。これにより、各ワーカーは独自のアプリケーション状態を持つことができます（後述）。
• App::new().service(index): 新しいAppインスタンスを作成し、.service()メソッドを使って定義したハンドラー関数（またはスコープ、リソースなど）を登録します。#[get("/")]属性が付いたindex関数は、自動的にサービスとして登録されます。
• .bind(("127.0.0.1", 8080))?: サーバーがリッスンするネットワークアドレスとポートを指定します。タプルでIPアドレスとポート番号を渡します。?演算子は、bindが返す可能性のあるResultのErrを、main関数の戻り値であるstd::io::Resultに伝播させています。
• .run().await: サーバーを起動し、非同期に実行します。awaitキーワードは、サーバーがシャットダウンされるまでここで待機することを意味します。サーバーが正常に起動すると、この非同期操作はstd::io::Result<Server>を返します。

プロジェクトのルートディレクトリ（my-actix-app）で以下のコマンドを実行してアプリケーションをビルドし、実行します。

bash
cargo run

ビルドが成功すると、サーバーが起動し、以下のような出力が表示されるはずです。

... (ビルド出力) ...
Listening on 127.0.0.1:8080

Webブラウザを開き、http://127.0.0.1:8080/にアクセスすると、「Hello, world!」というテキストが表示されるはずです。

これで、最初のactix-webアプリケーションが正常に動作しました。

第3章：ルーティングとリクエスト処理の詳細

Webアプリケーションの中核機能の一つは、受信したリクエストのURLパスとHTTPメソッドに基づいて、適切な処理を行うハンドラー関数にルーティングすることです。actix-webでは、様々な方法でルーティングを定義し、リクエストから必要な情報を抽出できます。

3.1 基本的なルーティング

前章で見たように、#[get("/")]のような属性マクロを使ってハンドラー関数を特定のルートに紐付けることができます。actix-webは、主要なHTTPメソッドに対応する属性マクロを提供しています。

• #[get("/path")]
• #[post("/path")]
• #[put("/path")]
• #[delete("/path")]
• #[head("/path")]
• #[patch("/path")]
• #[options("/path")]

また、特定のメソッドに限定せず、任意のメソッドでパスにマッチさせたい場合は#[route("/path", method="GET", method="POST")]のように複数指定したり、actix_web::web::to()ヘルパー関数と.route()メソッドを組み合わせる方法もあります。

“`rust
use actix_web::{web, App, HttpResponse, HttpServer, Responder};

async fn greet(req: actix_web::HttpRequest) -> impl Responder {
let name = req.match_info().get(“name”).unwrap_or(“World”);
HttpResponse::Ok().body(format!(“Hello {}!”, name))
}

async fn health_check() -> impl Responder {
HttpResponse::Ok().body(“OK”)
}

[actix_web::main]

async fn main() -> std::io::Result<()> {
HttpServer::new(|| {
App::new()
// 属性マクロを使用
.service(web::resource(“/health”).to(health_check)) // web::resource と .to() を使用
// パスパラメータを含むルート
.route(“/hello/{name}”, web::get().to(greet)) // web::method().to() を使用
})
.bind((“127.0.0.1”, 8080))?
.run()
.await
}
“`

この例では、異なる方法でルートを定義しています。
* web::resource("/health").to(health_check): /healthパスに対応するリソースを定義し、そこにhealth_checkハンドラーを紐付けています。デフォルトでは任意のリクエストメソッドを受け付けますが、.method()チェーンで制限できます。
* web::get().to(greet): これはweb::route("/hello/{name}", web::Method::GET).to(greet)の糖衣構文です。/hello/{name}というパスに対し、GETメソッドのリクエストだけをgreetハンドラーにルーティングします。

3.2 パスパラメータの抽出 (web::Path)

URLパスの一部を変数として抽出したい場合があります。例えば、/users/123のように、123をユーザーIDとして取得したいときです。actix-webでは、ルート定義で波括弧 {} を使ってパスセグメントに名前を付け、ハンドラー関数の引数としてweb::Pathエクストラクターを使用します。

“`rust
use actix_web::{web, App, HttpResponse, HttpServer, Responder};
use serde::Deserialize;

// パスパラメータを抽出するための構造体を定義
// Deserializeトレイトを derive することで、actix-webが自動的にパスセグメントをこの構造体にデシリアライズします。

[derive(Deserialize)]

struct Info {
user_id: u32,
}

// ハンドラー関数の引数に web::Path を指定
async fn get_user(info: web::Path) -> impl Responder {
HttpResponse::Ok().body(format!(“User ID: {}”, info.user_id))
}

[actix_web::main]

async fn main() -> std::io::Result<()> {
HttpServer::new(|| {
App::new()
// ルートパスにパラメータ {user_id} を定義
.route(“/users/{user_id}”, web::get().to(get_user))
})
.bind((“127.0.0.1”, 8080))?
.run()
.await
}
“`

この例では、/users/{user_id}というルートを定義し、{user_id}という名前のパスパラメータを指定しています。ハンドラー関数get_userは引数としてweb::Path<Info>を受け取ります。Info構造体はuser_idというフィールドを持ち、Deserializeトレイトを実装しています。actix-webは自動的にURLパスの{user_id}部分を抽出し、u32に変換してInfo構造体のインスタンスを作成し、それをハンドラーに渡します。

複数のパスパラメータを抽出したい場合は、タプルを使うか、複数のフィールドを持つ構造体を使います。

“`rust
// 複数のパスパラメータを構造体で抽出

[derive(Deserialize)]

struct UserProductPath {
user_id: u32,
product_id: u32,
}

async fn get_user_product(path: web::Path) -> impl Responder {
HttpResponse::Ok().body(format!(“User ID: {}, Product ID: {}”, path.user_id, path.product_id))
}

// ルート: /users/{user_id}/products/{product_id}
// … .route(“/users/{user_id}/products/{product_id}”, web::get().to(get_user_product)) …
“`

3.3 クエリパラメータの抽出 (web::Query)

URLのクエリ文字列（例: /search?q=rust&page=1）から情報を抽出するには、web::Queryエクストラクターを使用します。これはパスパラメータと同様に、Deserializeを実装した構造体を使って抽出します。

“`rust
use actix_web::{web, App, HttpResponse, HttpServer, Responder};
use serde::Deserialize;

// クエリパラメータを抽出するための構造体を定義

[derive(Deserialize)]

struct SearchInfo {
q: String,
page: Option, // オプションパラメータは Option で受け取ります
}

async fn search(info: web::Query) -> impl Responder {
let query = &info.q;
let page = info.page.map_or(1, |p| p); // pageが指定されていなければデフォルトで1

HttpResponse::Ok().body(format!("Searching for: '{}', Page: {}", query, page))

}

[actix_web::main]

async fn main() -> std::io::Result<()> {
HttpServer::new(|| {
App::new()
// ルート: /search?q=…&page=…
.route(“/search”, web::get().to(search))
})
.bind((“127.0.0.1”, 8080))?
.run()
.await
}
“`

/search?q=actixにアクセスすると「Searching for: ‘actix’, Page: 1」、/search?q=rust&page=2にアクセスすると「Searching for: ‘rust’, Page: 2」と表示されます。

3.4 リクエストボディの抽出 (web::Json, web::Form)

POST, PUTなどのリクエストでは、リクエストボディにデータが含まれることがよくあります（JSON形式やフォームデータなど）。actix-webはこれらのボディデータを自動的にパースし、Rustの構造体にデシリアライズするためのエクストラクターを提供しています。

3.4.1 JSONデータの抽出 (web::Json)

クライアントからJSON形式のデータが送られてくる場合、web::Jsonエクストラクターを使用します。この場合も、Deserializeを実装した構造体を定義します。

依存関係にserdeとserde_jsonを追加する必要があります。

toml
[dependencies]
actix-web = "4"
serde = { version = "1", features = ["derive"] } # derive feature が必要
serde_json = "1"

コード例：

“`rust
use actix_web::{web, App, HttpResponse, HttpServer, Responder};
use serde::{Deserialize, Serialize};

// リクエストボディ（JSON）を受け取るための構造体
// Serializeもderiveしておくと、レスポンスとしてJSONを返すときに便利です

[derive(Deserialize, Serialize)]

struct User {
name: String,
age: u32,
}

async fn create_user(user: web::Json) -> impl Responder {
// web::Json から内部の T を取り出すには .into_inner() を使います
let user_data = user.into_inner();
println!(“Received user: Name={}, Age={}”, user_data.name, user_data.age);

// 受け取ったデータをそのままJSONとして返す例
HttpResponse::Ok().json(&user_data)

}

[actix_web::main]

async fn main() -> std::io::Result<()> {
HttpServer::new(|| {
App::new()
// POSTメソッドで /users パスにJSONデータを受け付けるルート
.route(“/users”, web::post().to(create_user))
})
.bind((“127.0.0.1”, 8080))?
.run()
.await
}
“`

このエンドポイントに、例えばcurlを使って以下のようなJSONデータをPOSTリクエストで送信すると、サーバー側でデータが抽出されて処理されます。

bash
curl -X POST -H "Content-Type: application/json" -d '{"name": "Alice", "age": 30}' http://127.0.0.1:8080/users

3.4.2 フォームデータの抽出 (web::Form)

HTMLフォームから送信されるapplication/x-www-form-urlencoded形式のデータや、マルチパートフォームデータの一部として送信されるフィールドデータは、web::Formエクストラクターを使って抽出できます。これもDeserializeを実装した構造体を使います。

“`rust
use actix_web::{web, App, HttpResponse, HttpServer, Responder};
use serde::Deserialize;

// フォームデータを受け取るための構造体

[derive(Deserialize)]

struct FormData {
email: String,
password: String,
}

async fn signup(form: web::Form) -> impl Responder {
println!(“Received signup attempt: Email={}”, form.email);
// ここでデータベースへの登録などを行う…

HttpResponse::Ok().body(format!("User '{}' signed up successfully!", form.email))

}

[actix_web::main]

async fn main() -> std::io::Result<()> {
HttpServer::new(|| {
App::new()
// POSTメソッドで /signup パスにフォームデータを受け付けるルート
.route(“/signup”, web::post().to(signup))
})
.bind((“127.0.0.1”, 8080))?
.run()
.await
}
“`

このエンドポイントに、例えばcurlを使って以下のようなフォームデータをPOSTリクエストで送信できます。

bash
curl -X POST -d "[email protected]&password=mypassword" http://127.0.0.1:8080/signup

3.5 その他のエクストラクター (HttpRequest, web::Dataなど)

actix-webは他にも様々なエクストラクターを提供しています。

• HttpRequest: 生のHTTPリクエストオブジェクト全体にアクセスできます。ヘッダー、バージョン、URIなど、リクエストに関するあらゆる情報が含まれています。
• web::Data<T>: アプリケーション全体で共有される状態データにアクセスします（後述）。
• web::ReqData<T>: リクエストスコープで利用可能な状態データにアクセスします。
• web::Header<T>: 特定のヘッダー（例: User-Agent, Content-Type）の値を抽出します。
• web::Bytes: リクエストボディをバイト列としてそのまま取得します。

これらのエクストラクターは、ハンドラー関数の引数として必要なものを必要なだけ宣言して使用します。actix-webが依存性の注入（Dependency Injection）のように、適切なインスタンスを自動的に提供してくれます。

第4章：レスポンスの生成

ハンドラー関数は、クライアントへの応答となるHTTPレスポンスを生成する責任を持ちます。actix-webでは、レスポンスを生成するために様々な方法が提供されており、基本的にはResponderトレイトを実装した型を返します。

4.1 シンプルな文字列レスポンス

最も簡単なレスポンスは、文字列リテラルやStringを返すことです。これらはデフォルトでResponderを実装しています。

“`rust
async fn hello() -> impl Responder {
“Hello from actix-web!” // &str は Responder を実装
}

async fn greet_name(name: web::Path) -> String {
format!(“Hello {}!”, name.into_inner()) // String も Responder を実装
}
“`

これらの場合、actix-webは自動的にContent-Typeをtext/plainに設定し、ステータスコードを200 OKとします。

4.2 HttpResponseビルダー

より詳細にレスポンスを制御したい場合（ステータスコード、ヘッダー、カスタムボディなど）、HttpResponseビルダーを使用します。

“`rust
use actix_web::{HttpResponse, Responder};

async fn custom_response() -> impl Responder {
HttpResponse::Ok() // 200 OK レスポンスを開始
.content_type(“text/html”) // Content-Type ヘッダーを設定
.insert_header((“X-My-Header”, “some_value”)) // カスタムヘッダーを追加
.body(“

Hello!

This is an HTML response.

“) // レスポンスボディを設定
}

async fn not_found() -> impl Responder {
HttpResponse::NotFound().body(“Page not found”) // 404 Not Found
}

async fn created_user(user_id: web::Path) -> impl Responder {
HttpResponse::Created() // 201 Created
.append_header((“Location”, format!(“/users/{}”, user_id.into_inner()))) // Locationヘッダーを追加 (RESTful APIなどでよく使う)
.json(serde_json::json!({“status”: “success”, “user_id”: user_id.into_inner()})) // JSONボディを設定
}
“`

HttpResponse::build(StatusCode)で特定のステータスコードを持つビルダーを開始することもできます。

4.3 JSONレスポンス

API開発では、JSON形式のデータを返すのが一般的です。web::Jsonはリクエストボディの抽出だけでなく、レスポンスとしてJSONを返すためにも使用できます。Serializeトレイトを実装した任意の構造体をweb::Jsonでラップして返せます。

“`rust
use actix_web::{web, Responder};
use serde::{Deserialize, Serialize};

[derive(Serialize, Deserialize)]

struct User {
name: String,
age: u32,
}

async fn get_user_json() -> impl Responder {
let user = User { name: “Bob”.to_string(), age: 42 };
web::Json(user) // User構造体をJSONとして返す
}

// または HttpResponse::Ok().json(&user) としても同じ
“`

web::Json(value)は、HttpResponse::Ok().json(value)のショートカットのようなものです。ステータスコードを制御したい場合はHttpResponseビルダーを使います。HttpResponse::Ok().json(&value)は、valueをJSONにシリアライズしてボディに設定し、Content-Typeをapplication/jsonに設定します。

4.4 カスタムレスポンス型 (Responderの実装)

独自の型をレスポンスとして返せるようにしたい場合は、その型にResponderトレイトを実装します。これは、例えば特定のデータ形式（XML、YAMLなど）を返したい場合や、複雑なレスポンス生成ロジックを型の中にカプセル化したい場合に便利です。

Responderトレイトは一つの非同期メソッドasync_respond_to(self, req: &HttpRequest)を持ちます。このメソッドはHttpResponseまたはactix_web::Errorを返します。

“`rust
use actix_web::{http::header::ContentType, HttpRequest, HttpResponse, Responder, Scope};
use futures::future::LocalBoxFuture;

// XMLレスポンスを生成するカスタム型
struct XmlResponse(String);

impl Responder for XmlResponse {
type Body = actix_web::body::BoxBody; // actix-web 4.x から Body 型が BoxBody に変更
type Error = actix_web::Error; // レスポンス生成中に発生しうるエラー型

fn respond_to(self, _req: &HttpRequest) -> actix_web::Result<HttpResponse<Self::Body>> {
    let body = self.0;
    // HttpResponse::build() でレスポンスを構築
    let res = HttpResponse::Ok()
        .content_type(ContentType::new("application", "xml"))
        .body(body); // Body型は BoxBody を返す必要があるため、文字列を body() でラップする

    Ok(res)
}

// actix-web 4.x から async_respond_to は非推奨になり、respond_to のみが使用されます
// fn async_respond_to(self, req: &HttpRequest) -> LocalBoxFuture<'static, Result<HttpResponse<Self::Body>, Self::Error>> {
//     let res = self.respond_to(req);
//     Box::pin(async move { res }) // respond_to の結果を BoxFuture にラップ
// }

}

async fn get_xml() -> impl Responder {
let xml_data = “Hello XML!“.to_string();
XmlResponse(xml_data) // カスタム型を返す
}

[actix_web::main]

async fn main() -> std::io::Result<()> {
HttpServer::new(|| {
App::new()
.service(web::resource(“/xml”).to(get_xml))
})
.bind((“127.0.0.1”, 8080))?
.run()
.await
}
“`

Responderトレイトを実装することで、ハンドラー関数の戻り値として独自のセマンティクスを持つ型を使えるようになり、コードの表現力や再利用性が向上します。

第5章：アプリケーションの状態管理 (web::Data)

Webアプリケーションでは、データベースコネクションプール、設定情報、キャッシュなど、複数のリクエストやハンドラー関数間で共有したいリソースや状態が存在します。actix-webでは、このような共有可能な状態をweb::Dataエクストラクターを使って管理します。

web::Dataにラップされたデータは、アプリケーション起動時に一度だけ作成され、サーバーの全ワーカー、全リクエストから（イミュータブルな参照として）アクセス可能になります。

共有したい状態は、App::new()を返すクロージャの中で作成し、.app_data()メソッドを使ってAppに登録します。

“`rust
use actix_web::{web, App, HttpResponse, HttpServer, Responder};
use std::sync::Mutex; // 状態を可変にしたい場合は Mutex などを使用

// アプリケーションの状態を表す構造体を定義
// データベースコネクションプールや設定などを保持することが多い
struct AppState {
app_name: String,
counter: Mutex, // 複数リクエストから書き換える可能性のある状態は Mutex で保護
}

// Stateエクストラクターを使って状態にアクセスするハンドラー
async fn state_handler(data: web::Data) -> impl Responder {
let app_name = &data.app_name;
let mut counter = data.counter.lock().unwrap(); // Mutexをロック
*counter += 1; // カウンターをインクリメント

HttpResponse::Ok().body(format!("App Name: {}, Counter: {}", app_name, *counter))

}

[actix_web::main]

async fn main() -> std::io::Result<()> {
let counter = Mutex::new(0); // アプリケーション起動時に状態を作成

HttpServer::new(move || { // 外部の counter 変数をクロージャ内で利用するために move キーワードが必要
    App::new()
        // .app_data() メソッドで状態を登録
        // actix-web はこれを Arc<T> でラップし、複数ワーカー間で共有可能にする
        .app_data(web::Data::new(AppState {
            app_name: "My Actix-web App".to_string(),
            counter: counter.clone(), // Mutex は Clone 可能
        }))
        // 状態を使用するハンドラーを登録
        .route("/state", web::get().to(state_handler))
})
.bind(("127.0.0.1", 8080))?
.run()
.await

}
“`

解説：

• AppState構造体がアプリケーションの状態を定義しています。app_nameはイミュータブルなデータ、counterはミュータブルなデータとして定義しています。ミュータブルなデータは、複数のスレッド/ワーカーから安全にアクセスできるよう、std::sync::Mutexで保護されています。
• main関数内で、HttpServer::newのクロージャの外でcounterが作成され、そのクローンがクロージャにmoveされています。これは、HttpServer::newのクロージャがmoveキーワードを使用しているため、外部スコープの変数の所有権をキャプチャする必要があるからです。
• HttpServer::newのクロージャ内で、App::new()の後に.app_data(web::Data::new(AppState { ... }))を呼び出して、作成したAppStateインスタンスをアプリケーションの状態として登録しています。web::Data::new()は、データをArc<T>（アトミック参照カウンタ）でラップし、複数のワーカーやリクエストから安全に共有できるようにします。
• state_handlerハンドラー関数では、引数としてweb::Data<AppState>を受け取ります。これにより、登録されたAppStateインスタンスへの参照（実際にはArc<AppState>の内部への参照）にアクセスできます。
• data.app_nameは直接参照できます。data.counterはMutexでラップされているため、.lock().unwrap()を呼び出してロックを取得してから内部の値にアクセス・変更します。.lock()は非同期操作ではないため、ブロックする可能性がありますが、ウェブサーバーのコンテキストでは避けるべきです。非同期コンテキストでロックを取得する場合は、tokio::sync::Mutexのような非同期Mutexを使用することを検討してください。しかし、簡単なカウンターのような例ではstd::sync::Mutexでも大きな問題にならないことが多いです。

web::Dataは、データベースコネクションプール（sqlx::PgPool, diesel::r2d2::Poolなど）をアプリケーション全体で共有するのに非常に役立ちます。コネクションプールは通常Clone可能なので、Mutexでラップする必要はありません。

“`rust
use sqlx::PgPool;
// … その他の actix_web import

// アプリケーション状態にデータベースプールを追加
struct AppState {
db_pool: PgPool,
// … その他の状態
}

[actix_web::main]

async fn main() -> std::io::Result<()> {
// データベース接続プールの初期化 (非同期)
let pool = PgPool::connect(“postgres://user:password@host/dbname”).await.expect(“Failed to create pool.”);

HttpServer::new(move || { // move は pool をクロージャに移動
    App::new()
        .app_data(web::Data::new(AppState {
            db_pool: pool.clone(), // プールは Clone 可能
            // ... その他の状態
        }))
        // データベースを使用するハンドラーを登録
        // .service(...)
})
// ... bind and run

}

// データベースプールにアクセスするハンドラーの例
async fn get_data_from_db(data: web::Data) -> impl Responder {
// プールを使ってデータベース操作を実行 (非同期)
let result: (i64,) = sqlx::query_as(“SELECT $1”)
.bind(150_i64)
.fetch_one(&data.db_pool) // プールへの参照を渡す
.await
.expect(“Failed to fetch from DB”);

HttpResponse::Ok().body(format!("Value from DB: {}", result.0))

}
“`

第6章：ミドルウェアの活用

ミドルウェアは、リクエストの処理パイプラインに介入し、リクエストの前処理、レスポンスの後処理、あるいは特定の処理ロジック（認証、ロギング、セッション管理など）を複数のハンドラーで共有するための仕組みです。actix-webでは、.wrap()メソッドを使ってAppにミドルウェアを追加します。

actix-webはいくつかの組み込みミドルウェアを提供しています。

• Logger: リクエスト/レスポンスに関するロギングを行います。開発時やデバッグ時に非常に便利です。
• NormalizePath: 末尾のスラッシュの有無を正規化します（例: /usersと/users/を同じルートにマッチさせる）。
• Compress: レスポンスボディを圧縮します（Gzip, Brotliなど）。
• Session: セッション管理機能を提供します。
• actix_web::middleware::errhandlers::ErrorHandlers: カスタムエラーページなどを定義します。

これらのミドルウェアは、actix-web::middlewareモジュールや、対応する専用クレート（例: actix-session）から提供されます。

Loggerミドルウェアを追加する例：

“`rust
use actix_web::{middleware::Logger, App, HttpServer, Responder};

async fn index() -> impl Responder {
“Hello, world!”
}

[actix_web::main]

async fn main() -> std::io::Result<()> {
// 環境変数 RUST_LOG を設定することでロギングレベルを制御できます
// 例: RUST_LOG=info cargo run
std::env::set_var(“RUST_LOG”, “info”);
std::env::set_var(“RUST_BACKTRACE”, “1”); // エラー発生時にバックトレースを表示

// env_logger を初期化 (Logger ミドルウェアが使用)
env_logger::init();

HttpServer::new(|| {
    App::new()
        // .wrap() メソッドでミドルウェアを追加します
        // 複数のミドルウェアを追加する場合、追加した順序と逆の順序で実行されます (外側から内側へ)
        .wrap(Logger::default()) // デフォルト設定のLoggerミドルウェアを追加
        .service(actix_web::resource("/").to(index)) // ルートハンドラー
})
.bind(("127.0.0.1", 8080))?
.run()
.await

}
“`

この例では、env_loggerクレートを使ってロギングシステムを初期化し、actix-web::middleware::Logger::default()を.wrap()で追加しています。サーバーを起動してリクエストを送信すると、以下のようなログが出力されるはずです。

INFO actix_web::middleware::logger - 127.0.0.1:xxxxx "GET / HTTP/1.1" 200 13 "-" "curl/7.68.0"

これは、リクエストのIPアドレス、メソッド、パス、プロトコル、ステータスコード、レスポンスサイズ、Referer、User-Agentなどの情報を含むアクセスログです。

6.1 ミドルウェアの順序

複数のミドルウェアを.wrap()で追加する場合、その実行順序は重要です。App::new().wrap(MiddlewareA).wrap(MiddlewareB).service(handler)のように記述すると、リクエストはMiddlewareA -> MiddlewareB -> handlerの順に処理され、レスポンスはhandler -> MiddlewareB -> MiddlewareAの順に戻ります。つまり、リストの最後に.wrap()されたミドルウェアが最も内側（ハンドラーに近い側）で実行されます。

6.2 カスタムミドルウェアの実装

独自のミドルウェアを実装することも可能です。これにはTransformトレイトを使用します。Transformトレイトは、内部にServiceトレイトを実装した型を生成するファクトリのような役割を果たします。Serviceトレイトが実際のリクエスト処理の前後に介入するロジックを記述します。

カスタム認証ミドルウェアの骨格の例：

“`rust
use actix_web::{
dev::{Service, ServiceRequest, ServiceResponse, Transform},
Error, HttpResponse,
};
use futures::future::{ok, Ready};
use std::future::Future;
use std::pin::Pin;

// カスタムミドルウェアのファクトリ (Transformを実装)
pub struct Auth;

impl Transform for Auth
where
S: Service, Error = Error>,
S::Future: ‘static,
B: ‘static,
{
type Response = ServiceResponse;
type Error = Error;
type InitError = ();
type Transform = AuthMiddleware;
type Future = Ready>;

fn new_transform(&self, service: S) -> Self::Future {
    ok(AuthMiddleware { service })
}

// この call メソッドがリクエストごとに実行されます
fn call(&self, req: ServiceRequest) -> Self::Future {
    println!("Hi from start of middleware!"); // リクエスト前処理

    // ここで認証ロジックを実装する
    // 例: ヘッダーに Authorization トークンがあるかチェック
    let is_authenticated = if let Some(auth_header) = req.headers().get("Authorization") {
        // トークン検証ロジック...
        auth_header.as_bytes() == b"Bearer mysecrettoken"
    } else {
        false
    };

    if !is_authenticated {
        // 認証失敗の場合、ハンドラーには進まずここでレスポンスを返す
        let (request, _payload) = req.into_parts();
        let response = HttpResponse::Unauthorized().finish().map_into_boxed_body(); // 401 Unauthorized
        return Box::pin(async move { Ok(ServiceResponse::new(request, response)) });
    }

    // 認証成功の場合、次のサービス (別のミドルウェアかハンドラー) にリクエストを渡す
    let fut = self.service.call(req);

    Box::pin(async move {
        let res = fut.await?; // 次のサービスからのレスポンスを待つ

        println!("Hi from end of middleware!"); // レスポンス後処理
        Ok(res)
    })
}

// このメソッドで HTTP レスポンス本体を生成
fn error_response(&self) -> HttpResponse {
    HttpResponse::build(self.status_code())
        .json(serde_json::json!({
            "error": self.to_string(), // エラーメッセージをJSONとして返す
        }))
}

Ok(ServiceResponse::new(res.request().clone(), res))

Ok(ServiceResponse::new(res.request().clone(), res))

// #[actix_rt::test] 属性は非同期テストを実行するために必要
#[actix_rt::test]
async fn test_greet_ok() {
    // テスト用のAppインスタンスを作成
    let mut app = test::init_service(App::new().service(greet)).await;

    // テストリクエストを作成し、サービスを呼び出す
    let req = test::TestRequest::get().uri("/hello/Rust").to_request();
    let resp = test::call_service(&mut app, req).await;

    // レスポンスの検証
    assert!(resp.status().is_success()); // ステータスコードが2xxか
    assert_eq!(
        resp.headers().get(ContentType::name()).unwrap(),
        "text/plain"
    ); // Content-Type の検証

    // レスポンスボディの検証 (非同期でボディを読み込む)
    let body = test::read_body(resp).await;
    assert_eq!(body, actix_web::web::Bytes::from_static(b"Hello Rust!"));
}

#[actix_rt::test]
async fn test_greet_not_found() {
     let mut app = test::init_service(App::new().service(greet)).await;

    // 存在しないパスへのリクエスト
    let req = test::TestRequest::get().uri("/greet").to_request();
    let resp = test::call_service(&mut app, req).await;

    // 404 Not Found を期待
    assert_eq!(resp.status(), actix_web::http::StatusCode::NOT_FOUND);
}

HttpServer::new(|| {
    App::new()
        .service(index) // / へのリクエストはこのハンドラーが処理
        // /static/ 以下のリクエストは static ディレクトリからファイルを配信
        .service(fs::Files::new("/static", "static/").show_files_listing()) // show_files_listing() はディレクトリ内容表示を許可 (プロダクションではオフにすることが多い)
})
.bind(("127.0.0.1", 8080))?
.run()
.await

// 環境変数から設定をパース
let config = envy::from_env::<AppConfig>().expect("Failed to load configuration from environment");

// データベース接続プールを作成 (設定を使用)
// let pool = sqlx::PgPool::connect(&config.database_url).await.expect("Failed to create pool.");

HttpServer::new(move || {
    App::new()
        // 設定とプールをアプリケーション状態として登録
        .app_data(web::Data::new(config.clone()))
        // .app_data(web::Data::new(pool.clone()))
        // ... 他のサービス登録
})
.bind(("127.0.0.1", config.server_port))? // 設定からポートを読み込む
.run()
.await