Web基礎
Webアプリケーション開発の基礎概念を学びます。
Webの仕組み
クライアントとサーバー
┌─────────────┐ HTTP ┌─────────────┐
│ クライアント │ ──── リクエスト ────→ │ サーバー │
│ (ブラウザ) │ ←──── レスポンス ──── │ (Rustアプリ) │
└─────────────┘ └─────────────┘
- クライアント: ブラウザやアプリ。リクエストを送信
- サーバー: リクエストを受け取り、レスポンスを返す
HTTPプロトコル
HTTPリクエスト
GET /users/123 HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer token123
{リクエストボディ}
構成要素:
- メソッド: GET, POST, PUT, DELETE など
- パス:
/users/123 - ヘッダー: メタ情報
- ボディ: 送信データ(POST/PUTなど)
HTTPレスポンス
HTTP/1.1 200 OK
Content-Type: application/json
{"id": 123, "name": "Taro"}
構成要素:
- ステータスコード: 200, 404, 500 など
- ヘッダー: メタ情報
- ボディ: レスポンスデータ
HTTPメソッド
| メソッド | 用途 | 例 |
|---|---|---|
| GET | データ取得 | ユーザー情報を取得 |
| POST | データ作成 | 新規ユーザー登録 |
| PUT | データ更新(全体) | ユーザー情報を完全置換 |
| PATCH | データ更新(部分) | メールアドレスのみ更新 |
| DELETE | データ削除 | ユーザーを削除 |
ステータスコード
2xx: 成功
| コード | 意味 | 用途 |
|---|---|---|
| 200 | OK | 成功(一般的) |
| 201 | Created | リソース作成成功 |
| 204 | No Content | 成功(レスポンスボディなし) |
4xx: クライアントエラー
| コード | 意味 | 用途 |
|---|---|---|
| 400 | Bad Request | リクエストが不正 |
| 401 | Unauthorized | 認証が必要 |
| 403 | Forbidden | アクセス権限なし |
| 404 | Not Found | リソースが見つからない |
| 422 | Unprocessable Entity | バリデーションエラー |
5xx: サーバーエラー
| コード | 意味 | 用途 |
|---|---|---|
| 500 | Internal Server Error | サーバー内部エラー |
| 502 | Bad Gateway | 上流サーバーエラー |
| 503 | Service Unavailable | サービス利用不可 |
REST API
RESTful APIは、HTTPを使ってリソースを操作する設計パターンです。
REST設計の原則
- リソース指向: URLはリソースを表す(動詞ではなく名詞)
- HTTPメソッドで操作を表現: GET/POST/PUT/DELETE
- ステートレス: 各リクエストは独立
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メソッドは?
正解: B) POSTは新しいリソースの作成に使用します。GETは取得、PUTは更新(全体置換)、DELETEは削除です。
Q2. HTTPステータスコード「404」が意味するのは?
正解: C) 404 Not Foundは、リクエストされたリソースがサーバーに存在しないことを示します。4xxはクライアントエラー、5xxはサーバーエラーです。
Q3. 以下のAPIエンドポイント設計で、RESTの原則に反しているものは?
正解: C) RESTではURLは「リソース」を表し、操作はHTTPメソッドで表現します。「createUser」は動詞が入っているため不適切。正しくは POST /users です。
Q4. 以下のJSON文字列で構文エラーがあるのはどれ? { 'name': "Taro", "age": 25, "active": True }
正解: B) JSONではキーにシングルクォートは使えません('name'→"name")。また、真偽値は小文字で書きます(True→true)。
Q5. ブックマーク管理APIで「特定のブックマークを更新する」場合、RESTfulなエンドポイント設計は?
正解: A) RESTful設計では、リソース名(bookmarks)を使い、操作はHTTPメソッド(PUT)で表現します。URLに動詞(update)を含めるのは不適切です。
次のドキュメント: 02_axum_intro.md