Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Web基礎

Webアプリケーション開発の基礎概念を学びます。

Webの仕組み

クライアントとサーバー

┌─────────────┐         HTTP         ┌─────────────┐
│  クライアント │  ──── リクエスト ────→ │   サーバー   │
│  (ブラウザ)   │  ←──── レスポンス ──── │  (Rustアプリ) │
└─────────────┘                      └─────────────┘
  • クライアント: ブラウザやアプリ。リクエストを送信
  • サーバー: リクエストを受け取り、レスポンスを返す

HTTPプロトコル

HTTPリクエスト

GET /users/123 HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer token123

{リクエストボディ}

構成要素:

  1. メソッド: GET, POST, PUT, DELETE など
  2. パス: /users/123
  3. ヘッダー: メタ情報
  4. ボディ: 送信データ(POST/PUTなど)

HTTPレスポンス

HTTP/1.1 200 OK
Content-Type: application/json

{"id": 123, "name": "Taro"}

構成要素:

  1. ステータスコード: 200, 404, 500 など
  2. ヘッダー: メタ情報
  3. ボディ: レスポンスデータ

HTTPメソッド

メソッド用途
GETデータ取得ユーザー情報を取得
POSTデータ作成新規ユーザー登録
PUTデータ更新(全体)ユーザー情報を完全置換
PATCHデータ更新(部分)メールアドレスのみ更新
DELETEデータ削除ユーザーを削除

ステータスコード

2xx: 成功

コード意味用途
200OK成功(一般的)
201Createdリソース作成成功
204No Content成功(レスポンスボディなし)

4xx: クライアントエラー

コード意味用途
400Bad Requestリクエストが不正
401Unauthorized認証が必要
403Forbiddenアクセス権限なし
404Not Foundリソースが見つからない
422Unprocessable Entityバリデーションエラー

5xx: サーバーエラー

コード意味用途
500Internal Server Errorサーバー内部エラー
502Bad Gateway上流サーバーエラー
503Service Unavailableサービス利用不可

REST API

RESTful APIは、HTTPを使ってリソースを操作する設計パターンです。

REST設計の原則

  1. リソース指向: URLはリソースを表す(動詞ではなく名詞)
  2. HTTPメソッドで操作を表現: GET/POST/PUT/DELETE
  3. ステートレス: 各リクエストは独立

REST APIの例

# ユーザー一覧を取得
GET /users

# 特定のユーザーを取得
GET /users/123

# 新しいユーザーを作成
POST /users
Body: {"name": "Taro", "email": "taro@example.com"}

# ユーザーを更新
PUT /users/123
Body: {"name": "Taro", "email": "new@example.com"}

# ユーザーを削除
DELETE /users/123

URLの設計

# 良い例(名詞、複数形)
GET /users
GET /users/123
GET /users/123/posts
GET /posts?author=123

# 悪い例(動詞が入っている)
GET /getUsers
POST /createUser
GET /getUserById/123

JSON

Web APIでよく使われるデータ形式です。

JSON形式

{
  "id": 123,
  "name": "Taro",
  "email": "taro@example.com",
  "age": 25,
  "active": true,
  "tags": ["rust", "web"],
  "address": {
    "city": "Tokyo",
    "zip": "100-0001"
  }
}

RustでのJSON処理(serde)

#![allow(unused)]
fn main() {
use serde::{Deserialize, Serialize};

#[derive(Debug, Serialize, Deserialize)]
struct User {
    id: u32,
    name: String,
    email: String,
}

// JSONからRustの構造体へ
let json = r#"{"id": 1, "name": "Taro", "email": "taro@example.com"}"#;
let user: User = serde_json::from_str(json).unwrap();

// Rustの構造体からJSONへ
let json_output = serde_json::to_string(&user).unwrap();
}

Webアプリケーションの種類

1. APIサーバー(バックエンド)

クライアント ──JSON── APIサーバー ── データベース
  • JSONでデータをやり取り
  • フロントエンドと分離
  • 今回学ぶのはこれ

2. サーバーサイドレンダリング(SSR)

ブラウザ ←─HTML─ サーバー ── データベース
  • サーバーでHTMLを生成
  • 従来型のWebアプリ

3. 静的サイト + API

ブラウザ ←─HTML/JS─ 静的ファイル
    │
    └──JSON── APIサーバー
  • HTML/JSは静的配信
  • データはAPIから取得

Rustでの Web開発

主要なWebフレームワーク

フレームワーク特徴
Axumモダン、tokio製、型安全
Actix-web高性能、成熟
Rocket使いやすさ重視
Warpシンプル、コンポーザブル

このカリキュラムでは Axum を使用します。

なぜAxumか

  • tokioチームが開発(非同期との相性が良い)
  • 型システムを活かした安全な設計
  • モダンなRustの機能を活用
  • 活発なコミュニティ

まとめ

概念説明
HTTPクライアント-サーバー間の通信プロトコル
RESTリソース指向のAPI設計パターン
JSONデータ交換フォーマット
ステータスコード処理結果を表す数字
Rustでの対応
HTTPサーバー → Axum
JSON処理 → serde
非同期 → tokio

確認テスト

Q1. RESTful APIで「新しいユーザーを作成する」場合、適切なHTTPメソッドは?

Q2. HTTPステータスコード「404」が意味するのは?

Q3. 以下のAPIエンドポイント設計で、RESTの原則に反しているものは?

Q4. 以下のJSON文字列で構文エラーがあるのはどれ? { 'name': "Taro", "age": 25, "active": True }

Q5. ブックマーク管理APIで「特定のブックマークを更新する」場合、RESTfulなエンドポイント設計は?


次のドキュメント: 02_axum_intro.md