📌
HTTP通信とはHTTP（HyperText Transfer Protocol）は、ブラウザとWebサーバーが「会話」するためのルールです。 あなたがWebサイトを開いたりAPIを呼び出すとき、裏側ではすべてこのHTTPで通信が行われています。郵便に例えると、リクエスト＝手紙を送ること、レスポンス＝返事が届くことです。 手紙には「誰宛か」「何をしてほしいか」を書き、返事には「結果（成功/失敗）」と「中身（データ）」が書かれています。上のツールで▶ボタンを押して、1往復の通信がどのように流れるかを確認してみてください。 GET/POST/PUT/DELETEの4つのシナリオを切り替えると、メソッドごとの違いが分かります。
📌
HTTPの特徴- 🔄リクエスト-レスポンス型：必ず「クライアントが聞く→サーバーが答える」の1往復です。サーバー側から勝手にデータを送ることはありません（WebSocketは別の仕組み）。上のツールのステップ1→6がまさにこの1往復です。
- 📝テキストベース：HTTPメッセージは人間が読めるテキスト形式です。「生のHTTPテキストを表示」を開くと、実際にネットワーク上を流れる文字列が確認できます。デバッグしやすいのが大きな利点です。
- 🧊ステートレス（状態を持たない）：各リクエストは独立しており、サーバーは前回の通信を覚えていません。「初めてのお客さん」として毎回対応します。ログイン状態の維持にはCookieやトークンを使います。
- 🧩ヘッダーで拡張可能：HTTPヘッダーは自由に追加できるため、認証トークン・キャッシュ制御・言語設定など、あらゆる追加情報を付与できます。この柔軟性がHTTPの長寿命の理由のひとつです。
📌
ユースケース🌐 Webブラウジング
ブラウザでURLを入力すると、GETリクエストでHTMLを取得し画面を表示します。Chrome・Safari・FirefoxすべてHTTPで通信しています
🔌 REST API
フロントエンドとバックエンドのデータのやりとり。Twitter/X・GitHub・Stripeなど、ほぼ全てのWebサービスがHTTP APIを提供しています
📱 モバイルアプリ
スマホアプリもサーバーとHTTPで通信しています。LINEのメッセージ送信やInstagramの写真取得もHTTPリクエストです
🔗 Webhook / 外部連携
SlackやDiscordの通知連携、決済完了通知（Stripe Webhook）など、サーバー間の自動連携にもHTTPが使われています
📌
用語解説URL（Uniform Resource Locator）
＝ リソースの住所
URLはインターネット上のリソース（ページ・データ・画像など）の場所を示す文字列です。 郵便の「宛先住所」にあたります。上のツールではStatの「URL」欄に表示されています。https://api.example.com/api/users
プロトコル :// ホスト名 / パス
HTTPメソッド（HTTP Method）
＝ 「何をしたいか」を伝える動詞
リクエストの最初に書かれる「動作の種類」です。GET=取得、POST=作成、PUT=更新、DELETE=削除が代表的な4つです。 上のツールでシナリオを切り替えると、メソッドごとにリクエストの内容（ボディの有無など）が変わるのが確認できます。
ヘッダー（Header）
＝ メッセージの付帯情報
ヘッダーは手紙の封筒に書かれた情報にあたります。「誰宛か（Host）」「どんな形式で返してほしいか（Accept）」「どんなブラウザか（User-Agent）」など、データ本体以外のメタ情報を伝えます。 上のツールのRequest/Responseパネルに「Headers」として表示されています。Host: api.example.com
キー: 値 の形式で複数行書ける
ボディ（Body）
＝ 送受信するデータ本体
ボディは手紙の中身（便箋）にあたります。 リクエストではPOST/PUTで送信したいデータを、レスポンスではサーバーが返すデータを入れます。 GETリクエストにはボディがなく、DELETE + 204レスポンスにもボディがありません。上のツールでPOSTシナリオに切り替えると、リクエストにJSONボディが付く様子が確認できます。
ステータスコード（Status Code）
＝ 処理結果を示す3桁の数字
サーバーからの返事の最初に書かれる番号で、リクエストが成功したか、失敗したか、その理由を伝えます。 上のツールのStatの「ステータス」欄に、ステップ4以降で表示されます。2xx 成功 / 3xx リダイレクト / 4xx クライアントエラー / 5xx サーバーエラー
Content-Type
＝ データの形式を指定するヘッダー
ボディに入っているデータが「どんな形式か」をサーバーとクライアントの双方に伝える重要なヘッダーです。 JSON、HTML、画像など、形式によって処理方法が変わるため、正しく設定する必要があります。application/json — JSON
text/html — HTML
image/png — PNG画像
📌
HTTPメッセージの構造リクエストもレスポンスも、同じ3パート構成で書かれています。 上のツールの「生のHTTPテキストを表示」で実物を確認しながら読むと分かりやすいです。
リクエストの構造
① リクエストライン
GET /api/users HTTP/1.1
メソッド + パス + HTTPバージョン
② ヘッダー
Host: api.example.com
Accept: application/json
キー: 値 の形式で複数行
③ ボディ（任意）
{"name": "鈴木一郎"}
POST/PUTのときに付与
レスポンスの構造
① ステータスライン
HTTP/1.1 200 OK
HTTPバージョン + ステータスコード + 理由句
② ヘッダー
Content-Type: application/json
Content-Length: 156
レスポンスのメタ情報
③ ボディ
[{"id":1, "name":"田中太郎"}]
サーバーが返すデータ
ヘッダーとボディの間には必ず空行が1行入ります。この空行がヘッダーの終わりとボディの始まりを区切る目印です。
📌
ステータスコード早見表ステータスコードは百の位で大分類されています。開発中にエラーが出たら、まず百の位を見て原因の方向性を掴みましょう。
2xx成功
200 OKリクエスト成功。GETではデータを、PUT/DELETEでは結果を返す
201 Createdリソースの作成に成功。POSTで新規データを作ったとき
204 No Content成功したがボディなし。DELETEで削除完了したとき
3xxリダイレクト
301 Moved Permanentlyリソースが恒久的に移動。ブックマークを更新すべき
304 Not Modifiedキャッシュを使ってOK。データは変わっていない
4xxクライアントエラー
400 Bad Requestリクエストの形式が不正。JSONの構文ミスなど
401 Unauthorized認証が必要。ログインしていないか、トークンが無効
403 Forbidden認証済みだがアクセス権がない。管理者専用ページなど
404 Not Foundリソースが見つからない。URLの打ち間違いが多い
5xxサーバーエラー
500 Internal Server Errorサーバー側の予期せぬエラー。バグの可能性が高い
502 Bad Gatewayサーバー間の通信エラー。リバースプロキシの問題が多い
503 Service Unavailableサーバーが一時的に利用不可。メンテナンス中など
📌
HTTPメソッドの使い分け4つのメソッドはデータベース操作のCRUD（Create / Read / Update / Delete）に対応しています。 上のツールで各シナリオを試すと、メソッドごとにリクエストの内容（ボディの有無・レスポンスのステータスコード）が異なることが確認できます。
| メソッド | CRUD | ボディ | 冪等性 | 具体例 |
|---|
| GET | Read | なし | 冪等 | ユーザー一覧の取得 |
| POST | Create | あり | 非冪等 | 新しいユーザーの登録 |
| PUT | Update | あり | 冪等 | ユーザー情報の上書き更新 |
| DELETE | Delete | なし | 冪等 | ユーザーの削除 |
冪等（べきとう）とは？
同じリクエストを何度送っても結果が同じになる性質です。 GETは何度取得しても同じデータ。DELETEは2回目以降は「もう無い」ので同じ。 しかしPOSTは送るたびに新しいデータが作られます。
よくある間違い
「データを更新したいけどPOSTでいいや」→ これはREST設計では間違いです。 更新はPUT（全体置換）を使います。 POSTは「新規作成」専用と覚えましょう。
📌
HTTP通信の手順ブラウザでURLを入力してからページが表示されるまでの流れを、GET /api/users を例に追いかけます。 上のツールのステップスライダーと対応しているので、動かしながら読んでください。
1
リクエストを組み立てる
ブラウザが「何をしたいか」をテキストで組み立てます。GET /api/users HTTP/1.1
Host: api.example.com
Accept: application/json→「api.example.comさん、/api/usersのデータをJSON形式でください」という依頼です。
2
リクエストを送信する
組み立てたテキストをネットワーク経由でサーバーに送ります。 実際にはTCP（Transmission Control Protocol）という通信規格の上に乗せて、パケットに分割して届けます。 HTTPSの場合はTLS暗号化も行われます。
3
サーバーが処理する
サーバーがリクエストを解析し、メソッドとパスに応じた処理を実行します。 この例では「/api/usersに対するGET」なので、データベースからユーザー一覧を取得します。処理にかかる時間（レイテンシ）は、サーバーの性能やDBクエリの複雑さによって変わります。
4
レスポンスを返す
処理が完了したら、サーバーはレスポンスをクライアントに返します。HTTP/1.1 200 OK
Content-Type: application/json
[{"id":1,"name":"田中太郎"}, ...]→「成功しました。JSONでユーザー2名分のデータを返します」という回答です。
5
ブラウザがレスポンスを処理する
ブラウザがレスポンスを受信し、ステータスコードを確認します。200番台なら成功なので、Content-Typeに応じてボディを解釈します。 HTMLならページを描画、JSONならJavaScriptで処理、画像なら表示します。これで1往復のHTTP通信が完了です。Webページを1つ開くだけで、HTML・CSS・JS・画像など数十回のHTTP通信が発生しています。
📌
HTTPSとセキュリティHTTPはテキストがそのまま流れるため、第三者に盗み見される危険があります。 これを解決するのがHTTPS（HTTP over TLS）です。
HTTP（暗号化なし）
リクエスト/レスポンスが平文で流れるため、Wi-Fiの盗聴やパスワードの漏洩リスクがあります。 現在はほとんどのブラウザが「保護されていない通信」と警告します。
HTTPS（TLS暗号化）
TLS（Transport Layer Security）でHTTP通信を暗号化します。 アドレスバーの鍵マーク🔒が目印。Google・GitHub・Stripeなど、すべての主要サービスがHTTPSを使用しています。
覚えておくこと：自分のWebサービスを公開するときは、必ずHTTPSを設定しましょう。 Let's Encryptを使えば無料でTLS証明書を取得できます。
