はい、承知いたしました。Axum Rustを使ったモダンなWebアプリケーション開発の第一歩に関する詳細な記事を、約5000語で記述します。記事の内容を直接ここに表示します。

Axum Rust：モダンなWebアプリケーション開発の第一歩

はじめに

Webアプリケーション開発は、現代ソフトウェア開発の中核をなす分野です。日々進化する技術スタックの中で、安全性、パフォーマンス、そして開発効率は常に追求される目標となっています。Rust言語は、そのユニークな特性、特にメモリ安全性保証とゼロコスト抽象化により、これらの目標を達成するための強力な選択肢として注目を集めています。

Rustは、ガベージコレクションを持たずにメモリ安全性を保証し、CやC++に匹敵する実行速度を実現します。この特性は、特に高い並行性と低レイテンシが求められるWebサービスやAPIの開発において大きな強みとなります。しかし、Rustはその学習曲線が急峻であるとも言われます。所有権システム、借用チェッカー、ライフタイムといった概念は、Rust独自の考え方であり、習得には時間を要します。

それでもなお、一度Rustの哲学を理解すれば、その強力な型システムとコンパイラのチェックによって、実行時エラーの多くをコンパイル時に防ぐことができ、より堅牢で信頼性の高いコードを書くことが可能になります。Web開発においても、これはセキュリティの向上やランタイムクラッシュの減少に直結します。

RustでWebアプリケーションを開発するためのフレームワークはいくつか存在します。代表的なものとしては、Actix-web、Rocket、そしてAxumが挙げられます。

• Actix-web: 最も成熟しており、長年の開発実績を持つフレームワークの一つです。高いパフォーマンスに定評があります。アクターシステムに基づいている点が特徴です。
• Rocket: マクロを多用しており、非常に宣言的なスタイルで書けることが特徴です。開発体験が良いという評価もありますが、Nightly Rustに依存することが多い時期がありました（最近はStable対応も進んでいます）。
• Axum: Tokioエコシステムの一部として開発されており、タワー(Tower)ライブラリを基盤としています。非同期ランタイムTokioとの親和性が高く、ミドルウェアの柔軟性や、ExtractorとResponderを組み合わせたハンドラの表現力が特徴です。まだ比較的新しいフレームワークですが、TokioやTowerといった広く使われているコンポーネントの上に構築されているため、安定性やエコシステムとの連携に優れています。

この記事では、数あるRustのWebフレームワークの中からAxumに焦点を当て、その特徴、使い方、そしてモダンなWebアプリケーションを構築するための基本的なステップを詳細に解説します。Axumは、その設計思想と柔軟性から、特にマイクロサービスや高性能なAPIバックエンドを構築する上で魅力的な選択肢となっています。TokioやTowerといった他のRustエコシステムの重要なコンポーネントについても理解を深めることで、RustによるWeb開発の全体像を掴むことができるでしょう。

この記事を読むことで、あなたは以下のことを習得できます。

• Axumの基本的な構成要素と哲学。
• Axumを使った簡単なWebサーバーの構築方法。
• ルーティング、パスパラメータ、クエリパラメータの扱い方。
• JSONリクエスト/レスポンスの処理方法。
• アプリケーション状態の管理方法。
• ミドルウェアの利用方法。
• 基本的なエラーハンドリング。
• Axumアプリケーションのテスト方法。

RustでのWeb開発は、確かに学びが多い道のりです。しかし、Axumはその道のりをよりスムーズにし、Rustの持つパワーをWebアプリケーションとして最大限に引き出すための優れたツールとなるでしょう。さあ、モダンなRust Web開発の第一歩を踏み出しましょう。

Axumの基礎概念

Axumは、以下の主要なコンポーネントと設計哲学の上に構築されています。

1. Tokioエコシステム: Axumは非同期ランタイムとしてTokioを全面的に採用しています。非同期処理の実行、タイマー、I/O操作など、Webサーバーが必要とする非同期基盤は全てTokioが提供します。これにより、非同期処理を効率的に、かつ安全に扱うことができます。TokioはRustで最も広く使われている非同期ランタイムであり、その豊富なツール群やライブラリとの連携が容易です。
2. Towerライブラリ: Axumのもう一つの重要な基盤がTowerライブラリです。Towerは、ネットワークサービスの構成要素であるServiceトレイトを核とした非同期処理のための抽象化レイヤーを提供します。Axumのハンドラやミドルウェアは、このServiceトレイトに基づいて実装されています。これにより、異なるサービス（例えばHTTPサーバーとgRPCサーバー）間で共通のロジック（ミドルウェアなど）を共有したり、サービスを組み合わせたりすることが容易になります。ミドルウェアはTowerのLayerトレイトとして表現され、リクエスト処理パイプラインに機能を追加するために使用されます。
3. Hyper HTTPライブラリ: AxumはHTTPプロトコル処理のためにHyperライブラリを使用しています。HyperはRustで書かれた高速かつ正しいHTTP実装であり、多くのRust Webフレームワークで利用されています。AxumはHyperの上に構築されることで、低レベルなHTTPプロトコルの詳細から解放され、アプリケーションロジックに集中できます。
4. ExtractorとResponder: Axumのハンドラは、リクエストからデータを取り出すためのExtractorと、レスポンスを生成するためのResponderという概念に大きく依存しています。ハンドラ関数の引数は、FromRequestPartsまたはFromRequestBodyトレイトを実装するあらゆる型にすることができ、これらの型はリクエストの特定の要素（パスパラメータ、クエリパラメータ、JSONボディ、ヘッダーなど）を抽出します。同様に、ハンドラ関数の戻り値は、IntoResponseトレイトを実装するあらゆる型にすることができ、これらの型はHTTPレスポンスに変換されます。このExtractor/Responderパターンにより、ハンドラのシグネチャが非常に表現豊かになり、ボイラープレートコードを削減できます。
5. タプルによるハンドラ合成: 複数のExtractorをハンドラ関数の引数としてタプル形式で渡すことができます。Axumは自動的にこれらのExtractorを実行し、それぞれの抽出結果をハンドラに渡します。この機能により、複数の情報をリクエストから簡単に取り出すことができます。
6. Type Stateパターン: ルーターの設定において、特定のミドルウェア（例えばCorsLayer）が適用されたルーターは異なる型となり、次に適用できるミドルウェアや設定が制限されるというType Stateパターンが一部で利用されています。これにより、設定の順序に関する論理的な誤りをコンパイル時に検出できます。

これらの概念を理解することで、Axumがどのように動作し、その柔軟性や表現力がどこから来ているのかが見えてきます。特にTokioとTowerは、Axumだけでなく多くのRust非同期ライブラリの基盤となっているため、これらの理解はRustによる非同期プログラミング全般に役立ちます。

環境構築と最初のAxumアプリケーション

Axumアプリケーションを開発するための環境構築から始めましょう。

Rustのインストール

Rustをインストールしていない場合は、rustupという公式のツールチェインインストーラーを使ってインストールします。

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

このコマンドを実行すると、Rustコンパイラ（rustc）、Cargo（Rustのビルドシステムとパッケージマネージャー）、rustup自身がインストールされます。インストールが完了したら、シェルの設定ファイルを読み込むか、新しいターミナルを開いてください。

インストールが成功したか確認します。

bash
rustc --version
cargo --version

最新のStableバージョンがインストールされていればOKです。

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

次に、Cargoを使って新しいRustプロジェクトを作成します。ここでは、単純なWebアプリケーションを作成するので、実行可能ファイルを含むプロジェクトを作成します。

bash
cargo new my-axum-app
cd my-axum-app

これにより、my-axum-appというディレクトリが作成され、その中にCargo.tomlとsrc/main.rsが生成されます。

必要な依存関係の追加

Axumアプリケーションを構築するために、いくつかのクレート（Rustのライブラリ）を依存関係としてCargo.tomlに追加する必要があります。

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

“`toml
[dependencies]
axum = “0.7” # Axumフレームワーク本体
tokio = { version = “1”, features = [“full”] } # 非同期ランタイム（フル機能有効化）
tower = “0.4” # Towerライブラリ（主にServiceトレイトのインポートに必要）
tower-http = { version = “0.5”, features = [“full”] } # Towerベースの便利なミドルウェア集
serde = { version = “1”, features = [“derive”] } # 構造体のシリアライズ/デシリアライズ
serde_json = “1” # JSONのシリアライズ/デシリアライズ

ロギング（任意だが強く推奨）

tracing = “0.1”
tracing-subscriber = { version = “0.3”, features = [“env-filter”] }
“`

• axum: Axumフレームワーク本体です。バージョンを指定します。ここでは例として”0.7″系を指定していますが、最新版を使用してください。
• tokio: 非同期ランタイムです。features = ["full"]は、必要な機能（タイマー、I/O、マルチスレッディングなど）を全て有効にします。プロダクションでは必要な機能だけを有効にすることが推奨されますが、開発中は"full"が便利です。
• tower: Towerクレート自体を直接使うことは少ないかもしれませんが、Serviceトレイトなどをインポートするために必要になることがあります。
• tower-http: Towerベースの便利なHTTP関連ミドルウェアを集めたクレートです。ロギング、CORS、静的ファイル配信など、多くの一般的な機能が提供されています。features = ["full"]で全ての機能を有効にしています。
• serde, serde_json: Rustの構造体をJSON形式に変換（シリアライズ）したり、JSONから構造体に変換（デシリアライズ）したりするために使われます。特にJSON APIを構築する際に必須です。serdeのderiveフィーチャーは、構造体に#[derive(Serialize, Deserialize)]アトリビュートを付加することで、自動的にシリアライズ/デシリアライズのコードを生成するために必要です。
• tracing, tracing-subscriber: 構造化されたログ/トレースを出力するためのライブラリです。Webアプリケーションの状態を把握し、デバッグするために非常に役立ちます。tracing-subscriberは、tracingからの出力をどのように表示するかを設定します。env-filterフィーチャーは、環境変数（例: RUST_LOG=info）を使ってログレベルを制御できるようにします。

依存関係を追加したら、Cargoがそれらをダウンロードしてビルドできるようにします。

bash
cargo build

これでプロジェクトの基本的なセットアップは完了です。

基本的なAxumアプリケーション

src/main.rsを編集して、最初のAxumアプリケーションを作成します。最もシンプルな例として、”Hello, world!”を返すエンドポイントを持つWebサーバーを実装します。

“`rust
// 非同期ランタイムとしてTokioを使用することを宣言

[tokio::main]

async fn main() {
// ロギングの設定 (任意だが推奨)
tracing_subscriber::fmt()
.with_env_filter(“info”) // RUST_LOG環境変数でログレベルを制御
.init();

// ルーティングを設定
// "/" パスへのGETリクエストに対して、handler関数を実行する
let app = axum::Router::new().route("/", axum::routing::get(handler));

// サーバーを起動
let listener = tokio::net::TcpListener::bind("127.0.0.1:3000")
    .await
    .unwrap();
tracing::info!("listening on {}", listener.local_addr().unwrap());
axum::serve(listener, app).await.unwrap();

}

// HTTPリクエストを処理する非同期関数
async fn handler() -> String {
“Hello, world!”.to_string()
}
“`

コードの解説です。

• #[tokio::main]: main関数を非同期関数 (async fn) として実行できるようにするためのTokioマクロです。これにより、Tokioランタイムが設定され、main関数内で.awaitを使うことができます。
• tracing_subscriber::fmt().with_env_filter("info").init(): tracingクレートを使った基本的なロギング設定です。環境変数RUST_LOGが設定されていればそれを使用し、設定されていなければデフォルトでinfoレベル以上のログを出力するようにします。init()で設定を有効化します。
• axum::Router::new(): 新しいルーターを作成します。ルーターはどのパスへのリクエストをどのハンドラで処理するかを定義します。
• .route("/", axum::routing::get(handler)): ルーターに新しいルートを追加します。
  • 第一引数"/"は、マッチさせたいHTTPパスです。
  • 第二引数axum::routing::get(handler)は、そのパスへのリクエストのうち、GETメソッドの場合に実行するハンドラを指定します。axum::routingにはget, post, put, deleteなどのメソッドに対応した関数があります。
  • handlerは、このルートへのリクエストを実際に処理する非同期関数です。
• async fn handler() -> String: ハンドラ関数です。HTTPリクエストを処理するロジックを含みます。
  • Axumのハンドラは非同期関数 (async fn) である必要があります。
  • この例では引数を取りませんが、リクエストから情報（パスパラメータ、クエリ、ボディなど）を抽出したい場合は引数を追加します（後述のExtractor）。
  • 戻り値は、HTTPレスポンスに変換可能な型である必要があります。String型はAxumによって自動的に200 OKステータスコードとContent-Type: text/plainヘッダーを持つHTTPレスポンスに変換されます（IntoResponseトレイトの実装による）。
• tokio::net::TcpListener::bind("127.0.0.1:3000").await.unwrap(): 指定されたアドレス（ここではローカルホストのポート3000）でIncoming接続を待ち受けるTCPリスナーを作成します。これは非同期操作なので.awaitが必要です。unwrap()はエラーが発生した場合にパニックさせますが、実際にはより丁寧なエラーハンドリングが必要です。
• axum::serve(listener, app).await.unwrap(): 作成したTCPリスナーとAxumルーターを使ってHTTPサーバーを起動します。この関数はサーバーが停止するまで（例: プロセスが終了するまで）ブロックします。これも非同期操作です。

アプリケーションの実行

プロジェクトのルートディレクトリ（Cargo.tomlがある場所）で、以下のコマンドを実行します。

bash
cargo run

Cargoは依存関係をビルドし、src/main.rsのコードをコンパイルして実行します。成功すると、ターミナルに以下のような出力が表示されるはずです。

INFO my_axum_app::main: listening on 127.0.0.1:3000

Webブラウザやcurlなどのツールを使って、http://127.0.0.1:3000/にアクセスしてみてください。

bash
curl http://127.0.0.1:3000/

ターミナルにHello, world!と表示されれば成功です。

Ctrl+Cを押すとサーバーが停止します。

これで、Axumを使った基本的なWebサーバーの起動と、簡単なエンドポイントの実装ができました。これはAxum開発のまさに第一歩です。

ルーティングの詳細

AxumのRouterは、受信したHTTPリクエストのパスとメソッドに基づいて、実行すべきハンドラを決定します。Router::new()でルーターを作成し、.route()や.nest()などのメソッドを使ってルートを定義していきます。

メソッドによるルーティング

.route()メソッドは、指定したパスに対する特定のHTTPメソッド（GET, POSTなど）のハンドラを設定します。

“`rust
use axum::{
routing::{get, post},
Router,
};

async fn handler_get() -> String { “GET request”.to_string() }
async fn handler_post() -> String { “POST request”.to_string() }

let app = Router::new()
.route(“/resource”, get(handler_get).post(handler_post));
// 同じパスに対して複数のメソッドのハンドラを設定できる
“`

get(), post(), put(), delete(), patch(), head(), options(), trace()といった関数がaxum::routingモジュールで提供されており、それぞれのHTTPメソッドに対応します。.route()にこれらの関数をチェーンして繋げることで、同じパスに対する複数のメソッドのハンドラを定義できます。

any()を使うと、指定したパスへの全てのリクエストメソッドに対して同じハンドラを設定できます。

“`rust
use axum::{
routing::any,
Router,
};

async fn handler_any() -> String { “Any method request”.to_string() }

let app = Router::new()
.route(“/any-method”, any(handler_any));
“`

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

URLパスの一部をパラメータとして抽出し、ハンドラに渡すことができます。例えば、/users/123というパスから123というユーザーIDを抽出したい場合に使用します。

パスパラメータは、ルーターのパス定義で : の後にパラメータ名を記述します。ハンドラ関数では、axum::extract::Path Extractorを使用してパラメータを抽出します。

“`rust
use axum::{
extract::Path,
routing::get,
Router,
};

[tokio::main]

async fn main() {
// … logging setup …

let app = Router::new()
    .route("/users/:id", get(get_user)); // :id がパスパラメータ

// ... server setup ...

}

// async fn get_user(Path(user_id): Path) -> String { // 単一パラメータの場合
async fn get_user(Path(params): Path>) -> String { // 複数の場合、あるいは型変換に失敗する可能性がある場合
// println!(“Received user ID: {}”, user_id); // 単一パラメータの場合
// format!(“User ID: {}”, user_id) // 単一パラメータの場合

let user_id = params.get("id").expect("id must be present");
println!("Received user ID: {}", user_id);
format!("User ID: {}", user_id)

}
“`

Path<T>のTには、抽出したいパスパラメータの型を指定します。
* 単一のパスパラメータを抽出する場合、Path(parameter_name): Path<Type>のようにタプル構造分解と組み合わせるのが一般的です。例えば、Path(user_id): Path<u32>は、:idパラメータを抽出し、それをu32型に変換してuser_id変数にバインドします。型変換に失敗した場合、Axumは自動的に400 Bad Requestエラーレスポンスを返します。
* 複数のパスパラメータがある場合（例: /items/:category/:item_id）、あるいは型変換のエラーハンドリングを細かく制御したい場合は、Path<std::collections::HashMap<String, String>>や、パラメータ名をフィールドに持つ構造体（#[derive(Deserialize)]が必要）を使用することもできます。例ではHashMapを使っています。

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

URLのクエリ文字列（例: /search?query=rust&page=1）からパラメータを抽出するには、axum::extract::Query Extractorを使用します。

Query<T>のTには、クエリパラメータを保持するための構造体を指定します。この構造体には、クエリパラメータ名に対応するフィールドが必要です。#[derive(Deserialize)]を付加することで、serdeがクエリ文字列から構造体へのデシリアライズコードを生成します。

“`rust
use axum::{
extract::Query,
routing::get,
Router,
};
use serde::Deserialize;

[derive(Deserialize)]

struct Pagination {
page: Option,
per_page: Option,
}

[tokio::main]

async fn main() {
// … logging setup …

let app = Router::new()
    .route("/items", get(list_items));

// ... server setup ...

}

async fn list_items(Query(pagination): Query) -> String {
let page = pagination.page.unwrap_or(1);
let per_page = pagination.per_page.unwrap_or(10);

format!("Listing items - Page: {}, Items per page: {}", page, per_page)

}
“`

Query(pagination): Query<Pagination>のように記述することで、クエリ文字列がPagination構造体にデシリアライズされ、pagination変数にバインドされます。構造体のフィールドはOption<T>にすることで、パラメータが存在しなくてもエラーにならないようにできます。型変換に失敗した場合（例: page=abc）、Axumは400 Bad Requestを返します。

パスのワイルドカード (*)

特定のパスセグメント以降の全てのパスを捕捉するには、ワイルドカード*を使用します。例えば、/static/*pathは/static/css/style.cssや/static/images/logo.pngなどにマッチします。

ワイルドカードで捕捉されたパスの部分は、Path<String>またはPath<Vec<String>>として抽出できます（セグメントごとに分割されるか全体か）。ただし、通常は静的ファイル配信など、捕捉されたパスをサービスに渡す目的で使用されます。tower_http::services::ServeDirと組み合わせるのが一般的です。

“`rust
use axum::{
routing::get,
Router,
};
use tower_http::services::ServeDir;

[tokio::main]

async fn main() {
// … logging setup …

let app = Router::new()
    .route("/hello", get(|| async { "Hello!" }))
    // /static/ 以下のリクエストを ./static ディレクトリからファイルとして配信
    .nest_service("/static", ServeDir::new("static")); // ServeDirはTower Serviceを実装

// ... server setup ...

}
“`

この例では、/static/*pathのようなルーティングを直接定義する代わりに、nest_serviceメソッドを使っています。これは、特定のパスプレフィックス以下の全てのリクエストを、別のService実装（ここではServeDir）に委譲するための便利な方法です。

ネストされたルーター (Router::nest)

大規模なアプリケーションでは、関連するルートをグループ化し、それぞれを別のルーターとして定義したい場合があります。Router::nest()メソッドは、あるパスプレフィックス配下に別のルーターをマウントするために使用されます。

“`rust
use axum::{
routing::{get, post},
Router,
};

async fn list_users() -> String { “List users”.to_string() }
async fn create_user() -> String { “Create user”.to_string() }
async fn get_user(Path(id): Path) -> String { format!(“Get user: {}”, id) }

// ユーザー関連のルートを持つサブルーターを作成
fn users_routes() -> Router {
Router::new()
.route(“/”, get(list_users).post(create_user)) // /users と /users/ にマッチ
.route(“/:id”, get(get_user)) // /users/:id にマッチ
}

[tokio::main]

async fn main() {
// … logging setup …

let app = Router::new()
    .route("/", get(|| async { "Welcome!" }))
    .nest("/users", users_routes()); // /users 以下に users_routes をマウント

// ... server setup ...

}
“`

この例では、users_routes()関数がユーザー関連のルートをまとめたルーターを返します。main関数では、.nest("/users", users_routes())によって、/usersというパスプレフィックス以下にこのルーターをマウントしています。これにより、/usersへのGETリクエストはlist_usersに、/usersへのPOSTリクエストはcreate_userに、/users/123へのGETリクエストはget_userにルーティングされるようになります。

ルーターをネストすることで、コードが整理され、モジュール性が向上します。また、ネストされたルーター全体に特定のミドルウェアを適用することも容易になります。

ハンドラの作成と引数

Axumのハンドラは、HTTPリクエストを処理する中心的なロジックを含む非同期関数です。ハンドラ関数の最も強力な特徴の一つは、その引数として様々なExtractorを指定できることです。Axumはリクエストを受け取ると、ハンドラのシグネチャを見て必要なExtractorを実行し、その結果を関数の引数として渡します。

ハンドラ関数の基本的なシグネチャは以下のようになります。

rust
async fn some_handler(
// ここにExtractorを実装した型をカンマ区切りで並べる
// 例: Path<u32>, Query<MyQuery>, Json<MyRequestBody>
) -> impl axum::response::IntoResponse {
// リクエスト処理ロジック
// IntoResponseを実装した型（String, Json, StatusCodeなど）を返す
}

impl axum::response::IntoResponseは、戻り値がIntoResponseトレイトを実装していればどのような型でもよいことを示します。これにより、様々な種類のレスポンス（文字列、JSON、ステータスコード、ファイルなど）を返すことができます。

主要なExtractor

Axumは多くの便利な組み込みExtractorを提供しています。いくつか主要なものを紹介します。

axum::extract::Path

前述の通り、URLパスからパラメータを抽出します。

rust
async fn get_item(Path((category, item_id)): Path<(String, u32)>) -> String {
format!("Getting item '{}' from category '{}'", item_id, category)
}
// ルーティング: .route("/items/:category/:item_id", get(get_item))

複数のパスパラメータを抽出する場合、タプルや構造体（#[derive(Deserialize)]）を使用できます。

axum::extract::Query

クエリ文字列からパラメータを抽出します。#[derive(Deserialize)]付きの構造体を使用します。

“`rust

[derive(Deserialize)]

struct SearchParams {
q: String,
limit: Option,
}

async fn search(Query(params): Query) -> String {
let limit = params.limit.unwrap_or(10);
format!(“Searching for ‘{}’ with limit {}”, params.q, limit)
}
// ルーティング: .route(“/search”, get(search))
“`

axum::extract::Json

リクエストボディをJSONとしてパースし、#[derive(Deserialize)]付きのRust構造体に変換します。HTTPヘッダーContent-Type: application/jsonが必要です。

“`rust
use axum::Json;
use serde::Deserialize;
use serde_json::{Value, json}; // レスポンスでjson!マクロを使う例

[derive(Deserialize)]

struct CreateUser {
username: String,
email: String,
}

async fn create_user(Json(payload): Json) -> Json {
// 通常はここでデータベースに保存するなど
println!(“Creating user: {}”, payload.username);

// 成功レスポンスをJSONで返す
Json(json!({
    "status": "success",
    "message": "User created",
    "username": payload.username
}))

}
// ルーティング: .route(“/users”, post(create_user))
“`

Json<T>は、リクエストボディをTにデシリアライズするExtractorであると同時に、TをJSONレスポンスとしてシリアライズするIntoResponseの実装でもあります。上記の例では、戻り値の型もJson<Value>として、serde_json::json!マクロで構造化されたJSONを生成して返しています。

axum::extract::Form

リクエストボディをURLエンコードされたフォームデータ（application/x-www-form-urlencoded）またはマルチパートフォームデータ（multipart/form-data）としてパースし、#[derive(Deserialize)]付きのRust構造体に変換します。

“`rust
use axum::Form;
use serde::Deserialize;

[derive(Deserialize)]

struct LoginForm {
username: String,
password: String,
}

async fn login(Form(form): Form) -> String {
// 通常はここで認証処理
format!(“Login attempt for user: {}”, form.username)
}
// ルーティング: .route(“/login”, post(login))
“`

マルチパートフォームデータ（ファイルのアップロードなど）を扱う場合は、Formはmultipartクレートと連携します。

axum::extract::State

アプリケーション全体で共有される状態（データベース接続プール、設定オブジェクトなど）にアクセスするために使用します。ルーターに.with_state()メソッドで状態を追加する必要があります。

“`rust
use axum::{extract::State, routing::get, Router};
use std::sync::{Arc, Mutex};

[derive(Clone)] // Stateとして使用するにはCloneを実装する必要がある

struct AppState {
counter: Arc>,
}

[tokio::main]

async fn main() {
// … logging setup …

let shared_state = AppState {
    counter: Arc::new(Mutex::new(0)),
};

let app = Router::new()
    .route("/", get(increase_counter))
    .with_state(shared_state); // ルーターに状態を追加

// ... server setup ...

}

async fn increase_counter(State(state): State) -> String {
let mut counter = state.counter.lock().unwrap();
counter += 1;
format!(“Counter value: {}”, counter)
}
“`

State<T> Extractorを使うことで、ハンドラ関数内でアプリケーションの状態Tにアクセスできます。状態は通常、複数のリクエスト間で共有されるため、Arc（アトミック参照カウント）と、ミュータブルな共有のためにMutexやRwLockのような同期プリミティブと組み合わせて使用されます。Stateとして共有する型はCloneトレイトを実装している必要があります。

その他の主要なExtractor

• axum::extract::Extension: ミドルウェアの層を介してリクエストに付加されたデータにアクセスします。認証されたユーザー情報などをハンドラに渡す際によく使われます。
• axum::headers::Headers: リクエストヘッダー全体、または特定のヘッダーにアクセスします。axum::headersモジュールには多くの標準HTTPヘッダーに対応する型が定義されています（例: ContentType, UserAgent）。
• axum::body::Bytes: リクエストボディを生のバイト列として取得します。
• axum::body::Body: リクエストボディをストリームとして取得します。大きなボディを効率的に処理する場合に使用します。
• axum::extract::OriginalUri: リクエストの元のURIを取得します。
• axum::extract::ConnectInfo: クライアントのIPアドレスなど、接続に関する情報を取得します。TcpListenerにIncoming::into_make_service_with_connect_infoを使用する必要があります。
• axum::extract::Request: 生のHyperのRequestオブジェクト全体を取得します。Extractorが提供する以上の情報が必要な場合に使います。

複数のExtractorの使用

ハンドラ関数は複数のExtractorを引数として取ることができます。AxumはこれらのExtractorを順番に実行し、全てが成功した場合にのみハンドラ関数を実行します。Extractorの実行順序は基本的に自由ですが、ボディを消費するExtractor（Json, Form, Bytes, Body）は一度しか使用できません。また、ボディを消費するExtractorは、ボディを消費しないExtractorの後ろに置くのが一般的です。

“`rust
use axum::{
extract::{Path, Query, Json},
routing::post,
Router,
};
use serde::{Deserialize, Serialize};

[derive(Deserialize)]

struct UpdateItemPayload {
name: String,
price: f64,
}

[derive(Serialize)]

struct ItemUpdatedResponse {
id: u32,
name: String,
price: f64,
message: String,
}

[derive(Deserialize)]

struct OptionalQueryParams {
notify: Option,
}

async fn update_item(
Path(item_id): Path, // パスパラメータ
Query(query_params): Query, // クエリパラメータ
Json(payload): Json, // JSONボディ
) -> Json {
println!(“Updating item ID: {}”, item_id);
println!(“Payload: name={}, price={}”, payload.name, payload.price);
if query_params.notify.unwrap_or(false) {
println!(“Notification requested.”);
}

// 通常はここでデータベース更新など

Json(ItemUpdatedResponse {
    id: item_id,
    name: payload.name,
    price: payload.price,
    message: format!("Item {} updated successfully", item_id),
})

}
// ルーティング: .route(“/items/:id”, post(update_item))
“`

このハンドラは、パスパラメータ（item_id）、クエリパラメータ（notify）、そしてJSONリクエストボディ（name, price）を一度に抽出しています。非常に宣言的で分かりやすいシグネチャになります。

カスタムExtractorの実装

組み込みのExtractorで対応できない、より複雑なリクエストデータの抽出が必要な場合は、独自のカスタムExtractorを実装できます。カスタムExtractorは、axum::extract::FromRequestPartsまたはaxum::extract::FromRequestBodyトレイトを実装します。

例えば、特定のヘッダーが存在し、その値が正しい形式であることを保証しつつ抽出するExtractorを実装できます。これは、APIキーやトークンによる認証の初期段階などに利用できます。

これらのトレイトの実装はやや複雑になりますが、AxumのExtratorシステムの柔軟性を示しています。

レスポンスの生成

ハンドラ関数の戻り値は、axum::response::IntoResponseトレイトを実装している必要があります。このトレイトは、Rustの値をHTTPレスポンスに変換する方法を定義します。Axumは多くの一般的な型に対してこのトレイトを実装済みです。

基本的なレスポンス型

• String / &'static str: 200 OKステータスとtext/plainのContent-Typeを持つレスポンスになります。ボディは文字列の内容です。
• (): 200 OKステータスと空のボディを持つレスポンスになります。
• StatusCode: 指定したステータスコードを持つレスポンスになります。ボディは空です。
• Result<T, E>: TがIntoResponseを実装し、EもIntoResponseを実装している場合、Ok(T)はTをレスポンスに変換し、Err(E)はEをレスポンスに変換します。これはエラーハンドリングで非常に役立ちます。

“`rust
use axum::http::StatusCode;

async fn create_item_handler() -> StatusCode {
// アイテム作成ロジック…
let success = true; // 例

if success {
    StatusCode::CREATED // 201 Created
} else {
    StatusCode::BAD_REQUEST // 400 Bad Request
}

}
// ルーティング: .route(“/items”, post(create_item_handler))
“`

カスタムレスポンスの構築 (Response)

より詳細なレスポンス（特定のヘッダー、カスタムステータスコード、複雑なボディなど）を構築したい場合は、axum::response::Response型を直接構築するか、axum::response::IntoResponseトレイトを使ってレスポンスをカスタマイズします。

Responseを直接構築するのはやや手間がかかるため、通常はIntoResponseトレイトを実装した型を返すか、後述の便利なレスポンダーを使用します。

JSONレスポンス (Json)

前述の通り、axum::Json<T>型は、Tがserde::Serializeを実装している場合、TをJSON形式にシリアライズしてapplication/jsonのContent-Typeを持つレスポンスとして返します。

“`rust
use axum::Json;
use serde::Serialize;

[derive(Serialize)]

struct Item {
id: u32,
name: String,
price: f64,
}

async fn get_item_json(Path(item_id): Path) -> Json {
// データベースからアイテムを取得するロジック…
let item = Item { id: item_id, name: “Sample Item”.to_string(), price: 10.99 };

Json(item) // Item構造体をJSONにシリアライズして返す

}
// ルーティング: .route(“/items/:id”, get(get_item_json))
“`

リダイレクト (Redirect)

クライアントを別のURLにリダイレクトさせるには、axum::response::Redirectを使用します。

“`rust
use axum::response::Redirect;

async fn old_path_handler() -> Redirect {
Redirect::to(“/new-path”) // 303 See Other リダイレクトを返す
}
// ルーティング: .route(“/old-path”, get(old_path_handler))
“`

.to()は303 See Otherを、.permanent()は301 Moved Permanentlyを返します。

HTMLレスポンス (Html)

静的なHTML文字列を返すには、axum::response::Htmlを使用します。Content-Typeは自動的にtext/htmlになります。

“`rust
use axum::response::Html;

async fn render_html() -> Html<&’static str> {
Html(“

Hello from Axum!

This is HTML content.

“)
}
// ルーティング: .route(“/html”, get(render_html))
“`

より複雑なHTMLテンプレートエンジン（Askama, Tera, Handlebarsなど）と組み合わせる場合は、テンプレートエンジンが生成したStringをHtml()でラップして返すか、テンプレートエンジンの出力型自体がIntoResponseを実装するようにします。

その他のレスポンダー

AxumやTower-HTTPには、他にも様々な便利なレスポンダーが用意されています。

• tower_http::services::ServeFile: 単一のファイルをレスポンスとして配信します。
• tower_http::services::ServeDir: ディレクトリ内のファイルを静的ファイルとして配信します（前述の例）。
• axum::body::StreamBody: 非同期ストリームからレスポンスボディをストリーム配信します。大きなファイルやリアルタイムデータなどに使用できます。

これらのレスポンダーは、それぞれの型がIntoResponseを実装しているため、ハンドラから直接返すことができます。

アプリケーションの状態管理

Webアプリケーションでは、複数のリクエストやハンドラ間で共有される状態を持つことがよくあります。例えば、データベース接続プール、キャッシュ、アプリケーション設定、認証情報などがこれにあたります。Axumでは、axum::extract::State Extractorとaxum::Router::with_state()メソッドを使って状態を管理します。

状態として渡す型は、以下の条件を満たす必要があります。

1. 'staticライフタイムを持つこと（アプリケーションの生存期間中存在すること）。
2. Cloneトレイトを実装していること。Axumは各リクエストの処理前に状態をクローンしてハンドラに渡すためです。

ミュータブルな状態や共有リソース（データベース接続など）を扱う場合、スレッドセーフな方法で共有する必要があります。Rustでは、通常std::sync::Arcとstd::sync::{Mutex, RwLock}を組み合わせます。

• Arc<T>: スレッド間でT型のデータを安全に共有するための参照カウンタです。データを複数のスレッドから参照できますが、変更はできません。
• Mutex<T>: ミュータブルなデータTへの排他的アクセスを提供します。データにアクセスする際はロックを取得する必要があります。書き込みが多い場合に適しています。
• RwLock<T>: ミュータブルなデータTへの共有/排他的アクセスを提供します。複数のリーダーまたは単一のライターによるアクセスを許可します。読み取りが多い場合に適しています。

データベース接続プールのような共有リソースは、アプリケーション起動時に生成し、Arcでラップして状態としてルーターに渡すのが一般的なパターンです。

“`rust
use axum::{extract::State, routing::get, Router};
use std::sync::{Arc, Mutex};
use tokio::net::TcpListener;
use tracing::{info, Level};
use tracing_subscriber::FmtSubscriber;

// アプリケーション状態を定義
struct AppState {
// データベース接続プールなど、共有したいミュータブルなリソース
// ここでは簡単なカウンターの例
counter: Mutex,
// 設定値など、イミュータブルな共有データ
config: String,
}

// Stateとして使用するためにCloneを実装
impl Clone for AppState {
fn clone(&self) -> Self {
// MutexはCloneできないので、新しいMutexを初期値0で作成するのではなく、
// Arcと組み合わせてミュータブルなデータを共有するのが一般的。
// この例のAppStateはMutexを直接持っているため、
// 実際にはAppState自体をArcでラップする方が現実的。
// 例のため、ここではカウンターはクローンごとにリセットされると仮定（非現実的）
Self {
counter: Mutex::new(0), // この例は良くない実装です！
config: self.config.clone(),
}
}
}

// ★より現実的なAppStateの定義例 (Arc<Mutex<…>>を使用)
struct AppStateArc {
// アプリケーション全体で共有されるデータはArcでラップ
counter: Arc>,
// 設定など、クローン可能なデータはそのまま持てる
config: String,
}

impl Clone for AppStateArc {
fn clone(&self) -> Self {
Self {
counter: Arc::clone(&self.counter), // Arc::clone は参照カウントを増やすだけ
config: self.config.clone(),
}
}
}

[tokio::main]

async fn main() {
FmtSubscriber::builder()
.with_env_filter(“info”)
.init();

// ★現実的なAppStateArcの初期化
let shared_state_arc = AppStateArc {
    counter: Arc::new(Mutex::new(0)),
    config: "Some app config".to_string(),
};

let app = Router::new()
    .route("/", get(handler_with_state))
    .route("/config", get(handler_read_config))
    // ルーターに状態を追加
    .with_state(shared_state_arc); // AppStateArc全体をStateとして渡す

let listener = TcpListener::bind("127.0.0.1:3000").await.unwrap();
info!("listening on {}", listener.local_addr().unwrap());
axum::serve(listener, app).await.unwrap();

}

// State Extractorを使って状態にアクセス
async fn handler_with_state(State(state): State) -> String {
// Mutexをロックしてカウンターをインクリメント
let mut counter = state.counter.lock().unwrap(); // ロックの取得はブロッキング
*counter += 1;

format!("Counter: {}, Config: {}", *counter, state.config)

}

async fn handler_read_config(State(state): State) -> String {
// 読み取り専用のフィールドにアクセス
format!(“Config value: {}”, state.config)
}
“`

この改良された例では、ミュータブルなcounterをArc<Mutex<u32>>でラップしています。これにより、AppStateArc自体のクローンはArcの参照カウントを増やすだけで済み、複数のハンドラやスレッド間で同じカウンターインスタンスを安全に共有できるようになります。

State<T> Extractorは、指定された型の状態がルーターに.with_state(state)で追加されていることを期待します。複数の異なる種類の状態を共有したい場合は、それらをフィールドに持つ単一の構造体を作成し、その構造体を状態として渡すのが一般的です。

“`rust
// 複数の共有状態を持つ構造体の例
struct AppStateCompound {
db_pool: sqlx::PgPool, // 例: データベース接続プール
cache: Arc>, // 例: 共有可能なキャッシュ
config: AppConfig, // アプリケーション設定
}

// Clone を実装（各フィールドが Clone 可能である必要あり）
impl Clone for AppStateCompound {
fn clone(&self) -> Self {
Self {
db_pool: self.db_pool.clone(), // sqlx::PgPool は Clone を実装している
cache: Arc::clone(&self.cache), // Arc::clone
config: self.config.clone(), // AppConfig が Clone を実装している必要あり
}
}
}

// … main 関数内で初期化してルーターに追加 …
// let state = AppStateCompound { db_pool: …, cache: …, config: … };
// let app = Router::new().route(…).with_state(state);

// … ハンドラ内での使用 …
// async fn handler_needs_state(State(state): State) -> Result {
// let user = sqlx::query_as!(User, “SELECT id, username FROM users WHERE id = $1”, 1)
// .fetch_one(&state.db_pool) // db_pool を使用
// .await?;
// if let Some(cached_value) = state.cache.get(“some_key”) { // cache を使用
// println!(“Cached value: {}”, cached_value);
// }
// println!(“App config value: {}”, state.config.some_setting); // config を使用
// Ok(format!(“User: {}”, user.username))
// }
“`

このように、State ExtractorとArc/Mutex/RwLockを組み合わせることで、Rustの所有権と並行性のルールを守りながら、アプリケーション全体で安全に状態を共有できます。

ミドルウェア

ミドルウェアは、リクエストがハンドラに到達する前や、ハンドラがレスポンスを返した後に、共通の処理を挿入するための強力なメカニズムです。ログ出力、認証、CORS対応、圧縮、レート制限など、様々な横断的な concerns をミドルウェアとして実装できます。

AxumはTowerライブラリのミドルウェアシステムを全面的に採用しています。Towerでは、ミドルウェアはLayerトレイトとして定義され、サービス（Serviceトレイトを実装するもの、Axumのルーターやハンドラも含む）をラップして新しいサービスを作成します。

Axumルーターにミドルウェアを追加するには、.layer()メソッドを使用します。このメソッドはtower::Layerトレイトを実装したものを引数に取ります。tower-httpクレートには、多くの一般的なミドルウェアがLayerの実装として提供されています。

ミドルウェアは、ルーターに適用された順序で内側から外側へと実行されます。つまり、.layer(A).layer(B)と適用した場合、リクエストはまずBを通り、次にAを通り、その後にルーターに到達します。レスポンスは逆の順序（ルーター -> A -> B）で戻ります。

主要な組み込みミドルウェア (tower-http)

tower-httpクレートは、Axumと非常に相性の良い便利なミドルウェアを多数提供しています。Cargo.tomlでtower-httpの対応するフィーチャーを有効にする必要があります（features = ["full"]で全て有効にできます）。

• tower_http::trace::TraceLayer: リクエスト/レスポンスに関する詳細なログを出力します。tracingクレートと連携します。非常に便利で、ほとんどのアプリケーションで最初に加えるべきミドルウェアです。

“`rust
use axum::{routing::get, Router};
use tower_http::trace::TraceLayer;

[tokio::main]

async fn main() {
tracing_subscriber::fmt()
.with_env_filter(“info”)
.init();

let app = Router::new()
    .route("/", get(|| async { "Hello!" }))
    // TraceLayer を追加
    .layer(TraceLayer::new_for_http()); // HTTPリクエスト用に設定

// ... server setup ...

}
“`

TraceLayerは様々な設定が可能で、ログのフォーマットや、リクエスト/レスポンスのどの情報をログに含めるかなどをカスタマイズできます。

• tower_http::timeout::TimeoutLayer: リクエスト処理にタイムアウトを設定します。指定した時間内にレスポンスが返されない場合、リクエストはキャンセルされ、504 Gateway Timeoutなどが返されます。

“`rust
use axum::{routing::get, Router};
use tower_http::timeout::TimeoutLayer;
use std::time::Duration;
use tokio::time::sleep;

async fn slow_handler() -> String {
sleep(Duration::from_secs(5)).await; // 5秒待つ
“Done!”.to_string()
}

[tokio::main]

async fn main() {
// … logging setup …

let app = Router::new()
    .route("/slow", get(slow_handler))
    // 2秒のタイムアウトを設定
    .layer(TimeoutLayer::new(Duration::from_secs(2)));

// ... server setup ...

}
“`

/slowにアクセスすると、2秒後にタイムアウトエラーが発生します。

• tower_http::compression::CompressionLayer: レスポンスボディを自動的に圧縮します (gzip, brotliなど)。クライアントのAccept-Encodingヘッダーに応じて最適な圧縮方法を選択します。

“`rust
use axum::{routing::get, Router};
use tower_http::compression::CompressionLayer;

[tokio::main]

async fn main() {
// … logging setup …

let app = Router::new()
    .route("/", get(|| async { "Compress me!" }))
    // 応答圧縮を有効化
    .layer(CompressionLayer::new());

// ... server setup ...

}
“`

クライアントが圧縮をサポートしている場合、レスポンスは圧縮されて送信されます。

• tower_http::cors::CorsLayer: CORS (Cross-Origin Resource Sharing) を設定します。異なるオリジンからのHTTPリクエストを許可するかどうかなどを制御します。

“`rust
use axum::{routing::get, Router};
use tower_http::cors::CorsLayer;
use tower_http::cors::Any; // Any は全てを許可する場合に便利

[tokio::main]

async fn main() {
// … logging setup …

let app = Router::new()
    .route("/", get(|| async { "CORS enabled!" }))
    // 全てのオリジン、メソッド、ヘッダーを許可する最も緩い設定
    .layer(CorsLayer::new().allow_origin(Any).allow_methods(Any).allow_headers(Any));

// ... server setup ...

}
“`

CorsLayerは非常に多くの設定オプションを持ちます。本番環境では、許可するオリジン、メソッド、ヘッダーなどを制限することが強く推奨されます。

• tower_http::auth::RequireAuthorizationLayer: 認証ミドルウェア。特定のリクエストヘッダー（例: Authorization: Bearer token）をチェックし、認証が成功した場合のみリクエストを次のサービス（ハンドラなど）に進めます。失敗した場合は401 Unauthorizedや403 Forbiddenを返します。

“`rust
use axum::{routing::get, Router, extract::Extension};
use tower_http::auth::{RequireAuthorizationLayer, AuthorizeRequest};
use http::{Request, StatusCode};
use axum::body::Body;

// 認証状態をExtensionとしてハンドラに渡すための型
struct CurrentUser {
user_id: u32,
}

// RequireAuthorizationLayerに渡す認証ロジックを実装する型
struct MyAuthorizer;

impl AuthorizeRequest for MyAuthorizer {
type ResponseBody = Body; // 認証失敗時のレスポンスボディの型
type Future = std::future::Ready<Result<(), StatusCode>>; // 認証結果の非同期型

fn authorize(&mut self, request: &mut Request<Body>) -> Self::Future {
    // ★本来はここでRequestのヘッダーなどをチェックして認証ロジックを実行★
    // 例として、ここでは常に認証成功とみなし、Extensionを追加
    println!("Authorizing request...");
    let auth_success = true; // ダミーの認証結果

    let result = if auth_success {
        // 認証成功の場合、Extensionとしてユーザー情報を追加
        request.extensions_mut().insert(CurrentUser { user_id: 123 });
        Ok(()) // 認証成功
    } else {
        Err(StatusCode::UNAUTHORIZED) // 認証失敗 (401 Unauthorized)
    };

    std::future::ready(result)
}

}

[tokio::main]

async fn main() {
// … logging setup …

let app = Router::new()
    .route("/protected", get(protected_handler))
    // 認証ミドルウェアを追加
    // MyAuthorizerが認証ロジックを提供し、成功時にExtensionを追加
    .layer(RequireAuthorizationLayer::custom(MyAuthorizer));

// ... server setup ...

}

// protected_handler は Extension を Extractor として受け取る
// 認証ミドルウェアが成功した場合にのみ、このハンドラは実行され、CurrentUser が Extension として利用可能になっている
async fn protected_handler(Extension(user): Extension) -> String {
format!(“Welcome, user {}! This is a protected resource.”, user.user_id)
}
“`

この例では、MyAuthorizerがAuthorizeRequestトレイトを実装しており、ここで実際のリクエスト認証ロジックを記述します。認証が成功した場合、request.extensions_mut().insert(...)を使って認証済みユーザー情報などをExtensionとしてリクエストにアタッチできます。その後のハンドラでは、Extension<CurrentUser> Extractorを使ってこの情報を取り出せます。

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

Layerトレイトを実装することで、独自のカスタムミドルウェアを作成できます。これは、TowerのServiceトレイトの概念を理解している必要があります。

単純なカスタムミドルウェアの例として、リクエスト処理時間を計測してログに出力するミドルウェアを作成します。

“`rust
use axum::body::Body;
use http::{Request, Response};
use std::task::{Context, Poll};
use std::time::Duration;
use tower::{Layer, Service};
use tracing::info;

// ミドルウェア自体の設定を持つ型 (必要に応じて)

[derive(Clone)]

struct TimingMiddleware;

// Layer トレイトの実装
impl Layer for TimingMiddleware {
type Service = TimingService;

fn layer(&self, inner: S) -> Self::Service {
    TimingService { inner }
}

fn poll_ready(&mut self, cx: &mut Context<'_>) -> Poll<Result<(), Self::Error>> {
    // ラップしているサービスが準備できているか確認
    self.inner.poll_ready(cx)
}

fn call(&mut self, request: Request<Body>) -> Self::Future {
    let start = std::time::Instant::now(); // リクエスト開始時刻を記録
    let path = request.uri().path().to_string();

    // ラップしているサービスの call メソッドを呼び出す (次のミドルウェアまたはハンドラ)
    let future = self.inner.call(request);

    // 非同期ブロック内でレスポンスが返るのを待つ
    async move {
        let response = future.await?; // レスポンスを待つ
        let duration = start.elapsed(); // 処理時間を計算
        info!("Request to {} took {:?}", path, duration); // ログ出力
        Ok(response) // レスポンスをそのまま返す
    }
}

let app = Router::new()
    .route("/", get(|| async { "Hello!" }))
    // カスタムミドルウェアを適用
    .layer(TimingMiddleware);

let listener = TcpListener::bind("127.0.0.1:3000").await.unwrap();
info!("listening on {}", listener.local_addr().unwrap());
axum::serve(listener, app).await.unwrap();

    // エラーレスポンスのボディをJSONで返す例
    let body = Json(json!({
        "error": error_message,
    }));

    (status, body).into_response()
}

Ok(format!("Item details for ID: {}", item_id))

let app = Router::new()
    .route("/items/:id", get(get_item));

// ... server setup ...

// クライアントには汎用的なエラーコードを返す
StatusCode::INTERNAL_SERVER_ERROR

let app = Router::new()
    .route("/", get(main_handler))
    .layer(
        // ServiceBuilderを使って複数のレイヤーを組み合わせる
        ServiceBuilder::new()
            // HandleErrorLayer を追加し、エラー発生時に handle_error 関数を呼び出す
            .layer(HandleErrorLayer::new(handle_error))
            // 他のミドルウェアもここに追加できる（HandleErrorLayerの外側に置く）
            .timeout(Duration::from_secs(10)) // 例: タイムアウトミドルウェア
    );

// ... server setup ...

let task2 = task::spawn(async {
    sleep(Duration::from_secs(1)).await;
    "Result from task 2"
});

// 各タスクの完了を待って結果を取得
// .await はタスクが完了するまで待機
let result1 = task1.await.expect("Task 1 failed");
let result2 = task2.await.expect("Task 2 failed");

format!("Task 1: {}, Task 2: {}", result1, result2)

use axum::{
    body::Body,
    http::{Request, StatusCode},
    Router,
};
use tower::ServiceExt; // .oneshot() メソッドを使うために必要

// 非同期テスト関数を定義
#[tokio::test]
async fn basic_route_returns_hello_world() {
    // テスト対象のルーターを作成（必要なら状態も設定）
    let app = Router::new().route("/", get(|| async { "Hello, world!" }));

    // リクエストを構築
    let request = Request::builder()
        .uri("/")
        .body(Body::empty()) // ボディは空
        .unwrap();

    // ルーターをサービスとして呼び出し、レスポンスを取得
    // .oneshot() は ServiceExt トレイトが提供
    let response = app.oneshot(request).await.unwrap();

    // レスポンスを検証
    assert_eq!(response.status(), StatusCode::OK);

    let body = hyper::body::to_bytes(response.into_body()).await.unwrap();
    assert_eq!(&body[..], b"Hello, world!");
}

#[tokio::test]
async fn json_post_request() {
    use axum::Json;
    use serde::{Serialize, Deserialize};
    use serde_json::json;

    #[derive(Deserialize)]
    struct Input { name: String }
    #[derive(Serialize)]
    struct Output { message: String }

    async fn json_handler(Json(input): Json<Input>) -> Json<Output> {
        Json(Output { message: format!("Received: {}", input.name) })
    }

    let app = Router::new().route("/json", post(json_handler));

    let request_body = json!({ "name": "Axum" });

    let request = Request::builder()
        .method("POST")
        .uri("/json")
        .header("Content-Type", "application/json") // JSONリクエストにはContent-Typeが必要
        .body(Body::from(request_body.to_string()))
        .unwrap();

    let response = app.oneshot(request).await.unwrap();

    assert_eq!(response.status(), StatusCode::OK);
    assert_eq!(response.headers()["content-type"], "application/json");

    let body = hyper::body::to_bytes(response.into_body()).await.unwrap();
    let json_body: serde_json::Value = serde_json::from_slice(&body).unwrap();
    assert_eq!(json_body, json!({ "message": "Received: Axum" }));
}