Web Server
Web特有のサーバーサイド実装について説明します。
Web Server の特徴
HTTP プロトコル
- リクエスト/レスポンスモデル
- ステートレス通信
- RESTful API設計
- HTTP メソッド（GET, POST, PUT, DELETE）
セッション管理
- Cookie ベースセッション
- JWT (JSON Web Token)
- セッションストレージ
- CSRF対策
Web特有の考慮事項
- CORS (Cross-Origin Resource Sharing)
- Content Security Policy
- Same-Origin Policy
- XSS対策
技術スタック
Node.js
- Express.js
- Koa.js
- Fastify
- NestJS
Python
- Django
- Flask
- FastAPI
- Tornado
Ruby
- Ruby on Rails
- Sinatra
- Grape
その他
- PHP (Laravel, Symfony)
- Java (Spring Boot)
- C# (ASP.NET Core)
- Go (Gin, Echo)
API設計
REST API
- リソース指向設計
- HTTP ステータスコード
- エラーハンドリング
- バージョニング戦略
GraphQL
- スキーマ定義
- クエリ最適化
- リアルタイム通信
- N+1問題の解決
バリデーション考え方
ソフトウェア工学には**「ポステルの法則（ロバストネス原則）」**という有名な考え方があり、「送信するもの（自分の出力）には厳密に、受信するもの（他者からの入力）には寛容であれ」とされている。
具体的な考え方の違いは以下の通り。
- 外部APIからのレスポンス：柔軟に・壊れにくく（防衛的） 自分たちでコントロールできない外部システムに対しては、「システムを止めないこと」を最優先にバリデーションを設計する
なぜ柔軟にするのか: 外部APIは事前の告知なく仕様が変わる（新しいキーが増える、nullで返るはずがキーごと消える等）ことが日常茶飯事だからです。 実装のベストプラクティス: 業務ロジックの進行に絶対に必要な項目（IDやステータスなど）だけを厳格に必須とする。 それ以外の付随情報（今回の住所詳細など）は .nullish() にして、欠落していてもパースエラーでシステムを落とさないようにする。 定義していない未知のキーが追加されても無視する（Zodのデフォルト挙動）
厳格すぎた場合のリスク: 相手が「番地のフリガナ」を返し忘れただけで、こちらのコアな業務トランザクション全体がクラッシュするような「脆い（壊れやすい）システム」になってしまいます。
- フロントエンドからのリクエスト：強固に・厳格に（水際対策） 自分たちのシステムの入口（フロントエンドからのリクエスト）に対しては、「不正なデータをシステム内部に入れないこと」を最優先にバリデーションを設計します。 ⚬ なぜ厳格にするのか: 「クライアントからの入力は絶対に信用しない」がセキュリティとデータ整合性の鉄則だからです。 ⚬ 実装のベストプラクティス: ⚬ 必須項目、文字数制限、型（数値か文字列か）、フォーマット（正規表現など）を厳密に定義する。 ⚬ 予期せぬ余分なパラメータ（想定外のキー）が送られてきたら弾くか削ぎ落とす（Zodの .strict() など）。 ⚬ 柔軟すぎた場合のリスク: 不正なデータがDBに書き込まれたり、バックエンドの奥深くに到達してから「NullPointerException」等の予期せぬエラーを引き起こしたり、セキュリティホールに繋がります。 結論として、 「フロントエンドからの入力は**ホワイトリスト方式（許可したもの以外弾く）で厳格に守り、外部APIからの入力はブラックリスト/必須最小限方式（絶対必要なもの以外は許容する）**で柔軟に受け止める」という現在のアプローチは、非常に堅牢で実務的なアーキテクチャです。