WEB PROTOCOL
REST API（リクエスト/レスポンスモデル）
HTTPの標準的なリクエスト/レスポンスモデル。Stripe・GitHubのAPIで広く使われるステートレスなアーキテクチャスタイルです。
解説
1RESTとは
REST（Representational State Transfer）は、HTTPの標準的なリクエスト/レスポンスモデルを活用したリソース指向のアーキテクチャスタイルです。2000年にRoy Fieldingが博士論文で提唱しました。
Stripe・GitHub・Twitter（X）・AWSなど、世界中の主要なサービスがREST APIを提供しています。スマートフォンアプリ・Webフロントエンド・マイクロサービス間通信の主要な通信手段として広く使われています。
上のツールでステップを進めると、リクエスト構築 → 送信 → サーバー処理 → レスポンス → 完了の流れが確認できます。シナリオを切り替えてGET/POST/PUT/DELETEの違いも確かめてみましょう。
2RESTの特徴
- ①ステートレス（各リクエストが独立）：各HTTPリクエストはそれ自体で完結しており、サーバーは前のリクエストの情報を保持しません。認証情報はトークンとして毎回ヘッダーに付けて送る必要があります。この設計によりサーバーをスケールアウトしやすくなり、AWSのように何千台ものサーバーでリクエストを分散処理できます。
- ②統一インターフェース（CRUD操作がHTTPメソッドに対応）：リソース（ユーザー・注文・商品など）に対して、GET（取得）・POST（作成）・PUT（更新）・DELETE（削除）の4つのメソッドで操作します。URLはリソースを表し（
/api/users/42）、メソッドで操作を表す設計が世界標準となっています。 - ③キャッシュ可能（GETはキャッシュでき高速化できる）：GETリクエストはサーバー・CDN・ブラウザがキャッシュすることで、同じリクエストへの応答を大幅に高速化できます。
Cache-Control: max-age=60のようなヘッダーでキャッシュ戦略を細かく制御でき、APIのパフォーマンスとサーバー負荷を最適化できます。 - ④広い普及（全言語・フレームワークで対応）：REST APIは言語・プラットフォームを問わず利用できます。JavaScript・Python・Go・Rust・Swiftなど全ての言語でHTTPクライアントライブラリが提供されており、
curlコマンドやPostmanで即座にテストできる手軽さも大きな利点です。
3ユースケース
Web/モバイルAPI
Reactアプリやスマートフォンアプリからサーバーのデータを取得・更新するためのバックエンドAPI。Twitterのタイムライン取得やInstagramへの投稿などが典型例
マイクロサービス間通信
注文サービスが在庫サービスに商品確認を問い合わせるなど、独立したサービス間の連携。シンプルで標準化されたインターフェースが採用しやすい
サードパーティAPI（Stripe/Twilio）
決済処理（Stripe）・SMS送信（Twilio）・地図（Google Maps）など。REST APIを通じて外部の高度な機能を自分のアプリに組み込める
CRUDアプリ
ブログ・ECサイト・管理画面など、データの作成・読取・更新・削除が中心のアプリケーション。RESTのCRUDとDBのCRUDが自然に対応する
4用語解説
HTTPメソッド
＝ 操作の種類
＝ 操作の種類
GET（取得）/POST（作成）/PUT（更新）/DELETE（削除）の4種が基本です。同じURL
/api/users/42 でも、GETなら「ユーザー42を取得」、DELETEなら「ユーザー42を削除」という全く異なる操作を表します。メソッドによって冪等性（同じ操作を繰り返しても同じ結果になるか）も異なります。エンドポイント
＝ APIのURL
＝ APIのURL
/api/users/42 のようにリソースを表すURLです。42 はリソースのID（パスパラメータ）、/api/users?role=admin のようにクエリパラメータでフィルタリングもできます。RESTでは「名詞（リソース）をURLで表し、動詞（操作）をメソッドで表す」が設計原則です。ステータスコード
＝ 処理結果を表す3桁の数字
＝ 処理結果を表す3桁の数字
2xx=成功 / 4xx=クライアントエラー / 5xx=サーバーエラーに大別されます。200 OK（取得成功）・201 Created（作成成功）・204 No Content（削除成功）・404 Not Found（リソースなし）・401 Unauthorized（認証エラー）が頻出します。上のツールで各シナリオのレスポンスステータスの違いを確認できます。
JSON（応答フォーマット）
＝ APIレスポンスの標準フォーマット
＝ APIレスポンスの標準フォーマット
キーと値のペアで構造化データを表現するテキスト形式です。
Content-Type: application/json ヘッダーで指定します。全ての言語でパースライブラリが提供されており、JavaScriptでは JSON.parse() で即座にオブジェクトへ変換できます。配列・ネストした構造も自然に表現できます。5HTTPメソッドの使い分け
RESTではHTTPメソッドがCRUD操作に対応しています。冪等性（同じ操作を複数回実行しても結果が変わらない性質）はAPI設計の重要な概念です。
| メソッド | CRUD操作 | ボディ | 冪等性 | 典型的なURL |
|---|---|---|---|---|
| GET | Read（取得） | なし | ✓ あり | /api/users |
| POST | Create（作成） | あり | ✗ なし | /api/users |
| PUT | Update（全更新） | あり | ✓ あり | /api/users/42 |
| PATCH | Update（部分更新） | あり | △ 設計次第 | /api/users/42 |
| DELETE | Delete（削除） | なし | ✓ あり | /api/users/42 |
6通信の手順
0
初期状態
クライアントとサーバーが待機状態です。REST APIはステートレスで、各リクエストは独立して完結します。接続の維持は不要で、必要なときだけHTTPリクエストを送ります。
1
リクエスト構築
メソッド・URL・ヘッダー・ボディを組み立てます。認証トークン（Bearer）やContent-Typeなどのヘッダーを毎回付けて送る必要があります。これがステートレス設計の特徴で、サーバーは前のリクエストの情報を保持しません。
2
リクエスト送信
クライアントがHTTPリクエストをサーバーに送信中です。毎回TCPコネクションを新規確立（HTTP/1.1はKeep-Alive）してデータを送ります。WebSocketと違い、1回のやり取りで完結するのがRESTの特徴です。
3
サーバー処理
サーバーがDBアクセスやビジネスロジックを処理中です。GETリクエストはデータを読み取り、POST/PUT/DELETEは書き込み操作を行います。処理完了後、ステータスコードとレスポンスボディを組み立てます。
4
レスポンス構築
ステータスコード・レスポンスヘッダー・ボディを組み立てます。200 OKや201 Createdなどの3桁のステータスコードで処理結果を表します。Content-TypeにはJSONが標準的に使われます。
5
レスポンス送信
サーバーがHTTPレスポンスをクライアントに返送中です。レスポンスには処理結果のJSONデータが含まれます。この通信が完了したら接続は閉じられ、次のリクエストまでサーバーはクライアントの状態を保持しません。
6
通信完了
レスポンス受信完了です。クライアントはデータを受け取り、UIを更新します。REST APIの1サイクルが完了し、サーバーはこのリクエストに関する情報を破棄します。次のリクエスト時には再度認証情報を送る必要があります。
7ステータスコード一覧
2xx 成功
200 OK取得・更新成功。GETやPUTで最も一般的
201 Createdリソース作成成功。POST時にLocationヘッダーも返す
204 No Content成功だがボディなし。DELETEやPATCHで使用
3xx リダイレクト
301 Moved PermanentlyURLが恒久的に変更された。新URLへリダイレクト
304 Not Modifiedキャッシュが有効。ボディなしで高速化
4xx クライアントエラー
400 Bad Requestリクエスト形式が不正。バリデーションエラー
401 Unauthorized認証が必要。トークンがない・無効
403 Forbidden認証済みだが権限なし。閲覧不可のリソース
404 Not Foundリソースが見つからない。存在しないIDなど
422 Unprocessableバリデーションエラー。値が不正な場合
429 Too Many Requestsレートリミット超過。しばらく待って再試行
5xx サーバーエラー
500 Internal Server Errorサーバー内部エラー。バグやDB障害など
502 Bad Gatewayプロキシ先のサーバーが無効な応答を返した
503 Service Unavailableサーバー過負荷・メンテナンス中。一時的な障害
8セキュリティ
HTTPS必須
REST APIは必ずHTTPS（TLS/SSL）で暗号化して通信します。HTTP平文のままでは認証トークンやAPIキーが盗聴される危険があります。Let's Encryptなどで無料でTLS証明書を取得でき、現代では平文のHTTP REST APIは許容されません。
認証（Bearer Token / API Key）
RESTのステートレス設計では、すべてのリクエストに認証情報を付ける必要があります。Authorizationヘッダーに「Bearer {JWT}」を付けるJWT認証や、「X-API-Key: {key}」ヘッダーを使うAPIキー認証が代表的です。OAuthを使えばGoogleやGitHubのアカウントで認証できます。
CORS（Cross-Origin Resource Sharing）
ブラウザのセキュリティ機能で、異なるオリジン（ドメイン）からのAPIリクエストをサーバーが明示的に許可しないとブロックされます。サーバーはAccess-Control-Allow-Originヘッダーで許可するオリジンを指定します。誤って「*」（全許可）にすると脆弱性になるため注意が必要です。
Rate Limiting（レートリミット）
1つのIPやユーザーが短時間に大量のリクエストを送ることを制限します。DoS攻撃対策・APIの公平な利用・コスト管理のために必須です。429 Too Many Requestsステータスで制限を伝え、Retry-Afterヘッダーで待機時間を示します。GitHubは未認証で60req/h、認証済みで5000req/hです。
レスポンスの最小化
必要なフィールドだけをレスポンスに含め、パスワードハッシュや内部IDなど機密情報を返さないことが重要です。GraphQLのような選択的フィールド取得や、JSONのフィルタリングパラメータで返すデータを最小化します。エラーメッセージにも内部の実装詳細（スタックトレースやSQL文）を含めないよう注意します。
