MENU
プログラムとツールの使い方を、実務目線で分かりやすく整理
    1. ホーム
    2. 未分類
    3. HTTPの基本｜リクエストとレスポンスの仕組みを理解する

    HTTPの基本｜リクエストとレスポンスの仕組みを理解する

    未分類

    HTTPの基本｜リクエストとレスポンスの仕組みを理解する

    HTTPを理解すると、ブラウザがページを表示する流れも、APIがデータを返す流れも同じ土台で見えるようになります。

    実務では、Webページの表示不具合を調べるとき、API連携で 400 や 500 の原因を追うとき、フォーム送信やファイルアップロードの挙動を確認するときにHTTPの知識がそのまま役立ちます。

    • HTTPは、クライアントが送るリクエストと、サーバーが返すレスポンスで成り立つ
    • まず見るべきは メソッド URL ヘッダー ボディ ステータスコード
    • 例はHTTP/1.1の文字ベースで示すが、HTTP/2やHTTP/3でも意味の中心は同じ

    ここがポイント: HTTPは「何をほしいかを伝える依頼」と「その結果を返す返事」の約束事です。仕組みを分解して見ると、ブラウザ通信もAPI通信も読みやすくなります。

    目次

    HTTPで何ができるのか

    HTTPは、Webブラウザとサーバーの会話だけの話ではありません。現在はAPI、モバイルアプリ、社内ツール、外部サービス連携でも広く使われています。

    たとえば次のような場面です。

    • ブラウザがHTML、CSS、画像を取得する
    • フォームからユーザー情報を送信する
    • JavaScriptがAPIからJSONを取得する
    • 社内バッチが外部APIへデータを登録する
    • 監視ツールがステータス確認用エンドポイントを叩く

    HTTPは「どの資源に対して」「何をしたいか」を伝える共通ルールなので、画面表示でもシステム連携でも同じ考え方で追えます。

    前提として押さえたい構成

    ここでは、MDNとHTTP標準仕様に沿って、HTTP/1.1の読みやすい形で説明します。メッセージの意味はHTTP/2やHTTP/3でも共通です。

    HTTP通信の基本構成は次の2つです。

    リクエスト

    クライアントがサーバーに送る依頼です。

    GET /products/123 HTTP/1.1
Host: example.com
Accept: application/json

    この短い通信でも、最低限の情報が入っています。

    • GET: 何をしたいか。今回はデータ取得
    • /products/123: どの資源を対象にするか
    • HTTP/1.1: どのHTTP形式で通信するか
    • Host: どのホスト宛てか
    • Accept: どんな形式の返答を受け取りたいか

    レスポンス

    サーバーが返す結果です。

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

{"id":123,"name":"Keyboard","price":4980}

    見るべきポイントは次の通りです。

    • 200 OK: 処理結果。成功か失敗かを示す
    • Content-Type: 中身の種類。JSONなのかHTMLなのか
    • Content-Length: 本文サイズ
    • 本文: 実際に返ってきたデータ

    リクエストはどう組み立てられるか

    HTTPリクエストは、実務で見るときに4つへ分けると理解しやすくなります。

    1. メソッド

    メソッドは、サーバーに何をしてほしいかを示します。

    • GET: データ取得
    • POST: 新規作成や送信
    • PUT: 全体更新
    • PATCH: 一部更新
    • DELETE: 削除
    • HEAD: 本文なしで情報だけ確認
    • OPTIONS: 使える通信方法を確認

    初心者がまず押さえるなら、GET と POST を区別できればかなり前に進めます。

    • GET: 一覧表示、詳細表示、検索結果取得
    • POST: ログイン送信、問い合わせ送信、APIへの登録

    2. URL

    URLは「どこに依頼するか」です。

    https://api.example.com/users/42?expand=profile

    このURLなら、見るポイントは次の通りです。

    • https: 通信方式。通常は暗号化されたHTTPSを使う
    • api.example.com: 接続先ホスト
    • /users/42: 対象リソース
    • ?expand=profile: 追加条件を表すクエリ文字列

    実務では、同じメソッドでもURLが違えば意味が変わることが多いです。

    • GET /users: ユーザー一覧
    • GET /users/42: ユーザー詳細

    3. ヘッダー

    ヘッダーは本文そのものではなく、通信に関する付加情報です。

    よく使うものは次の通りです。

    • Host: 接続先ホスト名
    • Accept: 受け取りたいデータ形式
    • Content-Type: 送る本文の形式
    • Authorization: 認証情報
    • User-Agent: クライアント情報
    • Cookie: セッション情報

    たとえばAPIへJSONを送るときは Content-Type: application/json が重要です。これがずれると、本文が正しくてもサーバー側で解釈に失敗することがあります。

    4. ボディ

    ボディは、サーバーへ渡す実データです。主に POST PUT PATCH で使います。

    POST /users HTTP/1.1
Host: api.example.com
Content-Type: application/json

{"name":"Sato","email":"sato@example.com"}

    この本文はJSONです。フォーム送信なら application/x-www-form-urlencoded、ファイルアップロードなら multipart/form-data が使われることもあります。

    レスポンスはどう読めばよいか

    レスポンスは「成功したか」だけでなく、何が返ってきたかまで見る必要があります。

    1. ステータスコード

    最初に見るべき値です。

    • 1xx: 処理途中
    • 2xx: 成功
    • 3xx: 転送や再取得が必要
    • 4xx: リクエスト側の問題
    • 5xx: サーバー側の問題

    実務でよく出るものを絞ると、次の把握で十分です。

    • 200 OK: 正常に取得できた
    • 201 Created: 新規作成できた
    • 204 No Content: 成功したが返す本文はない
    • 301 302: 別の場所へ移動
    • 400 Bad Request: 送信内容が不正
    • 401 Unauthorized: 認証が必要、または認証失敗
    • 403 Forbidden: 権限不足
    • 404 Not Found: 対象が見つからない
    • 500 Internal Server Error: サーバー内部エラー
    • 503 Service Unavailable: 一時的に利用不可

    同じ失敗でも意味はかなり違います。たとえば 404 はURLやIDの誤りを疑い、500 はサーバー処理やアプリのログ確認に進むべきです。

    2. レスポンスヘッダー

    レスポンスヘッダーは、本文の読み方や次の動作を決める材料です。

    よく見るものは次の通りです。

    • Content-Type: HTMLかJSONか画像か
    • Content-Length: 本文サイズ
    • Location: リダイレクト先や作成済みリソースの場所
    • Cache-Control: キャッシュ方針
    • Set-Cookie: Cookieの保存指示

    APIデバッグでは、本文だけ見ていると原因を取りこぼします。たとえば 201 Created のレスポンスで Location が返っていれば、新しく作られたリソースのURLを次の処理で使えます。

    3. レスポンスボディ

    レスポンスボディには、取得結果やエラー内容が入ります。

    {
  "error": "invalid_parameter",
  "message": "email is required"
}

    このようなエラー本文があれば、単に「失敗した」で終わらず、どの入力が問題かまで追えます。HTTPはステータスコードと本文を合わせて読むのが基本です。

    実務で多い流れを1本で見る

    理屈だけだとつかみにくいので、ユーザー作成APIの流れで見てみます。

    リクエスト例

    POST /api/users HTTP/1.1
Host: api.example.com
Content-Type: application/json
Accept: application/json
Authorization: Bearer <token>

{
  "name": "Yamada",
  "email": "yamada@example.com"
}

    レスポンス例

    HTTP/1.1 201 Created
Content-Type: application/json
Location: https://api.example.com/api/users/501

{
  "id": 501,
  "name": "Yamada",
  "email": "yamada@example.com"
}

    このやり取りで読めることは明確です。

    • POST なので新規作成の依頼
    • JSONを送るので Content-Type: application/json
    • Authorization があるので認証付きAPI
    • 201 Created なので作成成功
    • Location があるので作成済みリソースのURLも分かる
    • 本文に作成結果が入っているので、画面表示や後続処理に使える

    HTTPの理解が浅いと「APIが動いたかどうか」だけ見がちですが、実務ではどのヘッダーが必要か、返答のどこを次の処理で使うかまで読むことが重要です。

    ブラウザとAPIで見え方はどう違うか

    HTTPの土台は同じでも、ブラウザ表示とAPI連携では注目点が少し変わります。

    ブラウザでよく見るもの

    • HTML取得の GET
    • CSS、JavaScript、画像の追加リクエスト
    • 302 などのリダイレクト
    • Set-Cookie によるログイン維持
    • キャッシュ関連ヘッダー

    APIでよく見るもの

    • Content-Type: application/json
    • Authorization ヘッダー
    • POST PUT PATCH DELETE
    • 400 401 403 422 などの入力・認証エラー
    • JSON本文に含まれるエラーメッセージ

    この違いを意識すると、ブラウザの開発者ツールやAPIテストツールで何を見るべきかが早く決まります。

    よくある失敗と見直しポイント

    HTTPでつまずく原因は、派手な理論より基本項目の見落としであることが多いです。

    400 Bad Request が出る

    よくある原因です。

    • JSONの構文が壊れている
    • 必須パラメータが不足している
    • Content-Type が実データ形式と合っていない
    • URLのクエリ指定が誤っている

    まずは本文、ヘッダー、API仕様の3点を並べて確認します。

    401 と 403 を混同する

    似ていますが意味は別です。

    • 401: 認証情報がない、または無効
    • 403: 認証は通っているが権限が足りない

    ここを取り違えると、トークン再発行が必要なのか、権限設定の見直しが必要なのかがずれます。

    GET にボディを送れば何でも動くと思う

    HTTPの仕様や実装では、メソッドごとに期待される使い方があります。データ取得、作成、更新、削除をメソッドで分ける前提で多くのAPIやツールが作られているため、仕様書どおりのメソッドを使うのが基本です。

    本文だけ見てヘッダーを見ない

    実務ではこれがかなり多いです。

    • JSONのつもりで見たら実際はHTMLエラーページだった
    • 文字化けの原因が Content-Type だった
    • リダイレクトで別URLへ飛ばされていた
    • キャッシュにより古いデータを見ていた

    NetworkタブやAPIテストツールでは、本文だけでなくヘッダーも必ず確認した方が早く原因に届きます。

    HTTPを確認する代表的な方法

    理解を定着させるには、実際に通信を観察するのが近道です。

    • ブラウザの開発者ツール Network タブ
    • curl でのAPIリクエスト確認
    • PostmanなどのAPIテストツール
    • サーバーログやアプリケーションログの突き合わせ

    特に初心者には、ブラウザの Network タブで1本のリクエストを開き、次の順で見る方法がおすすめです。

    1. URL
    2. メソッド
    3. ステータスコード
    4. リクエストヘッダー
    5. リクエスト本文
    6. レスポンスヘッダー
    7. レスポンス本文

    この順番で見る癖がつくと、APIでもWeb画面でも同じ見方ができます。

    HTTP/1.1とHTTP/2とHTTP/3の違いはどこまで気にするべきか

    入門段階では、まず意味を理解することが先です。

    MDNでも、HTTP/2ではメッセージがバイナリフレーム化される一方で、基礎となる意味はHTTP/1.xの理解から学べると整理されています。つまり、メソッド、ヘッダー、ステータスコード、ボディの役割をHTTP/1.1形式で理解しておけば、実務の入り口としては十分です。

    細かい違いとしては次の程度を知っておけば足ります。

    • HTTP/1.1: 文字ベースで読みやすい
    • HTTP/2: 高速化のための多重化やバイナリ化がある
    • HTTP/3: QUICを使い、接続面の改善がある

    ただし、API仕様書を読む、エラーを切り分ける、ブラウザ通信を追う、といった日常業務では、まずリクエストとレスポンスの意味を正確に読む力が効きます。

    関連ツールと使い分け

    HTTPを学ぶときは、用途に応じて道具を分けると効率が上がります。

    • ブラウザの通信確認: 開発者ツール
    • API疎通確認: curl
    • 繰り返しテスト: Postman
    • 自動処理への組み込み: Python、Node.js、ShellなどのHTTPクライアント

    学習順としては、まずブラウザで見える通信を観察し、その後で curl やコードから同じHTTPを再現すると理解が深まります。

    まとめ

    HTTPの基本は難しくありません。見るべき場所を固定すれば、通信の意味が読み取れるようになります。

    • リクエストは「何を、どこへ、どう送りたいか」
    • レスポンスは「結果がどうなり、何が返ったか」
    • 最初に見るべきは メソッド URL ヘッダー ボディ ステータスコード
    • エラー調査では、本文だけでなくヘッダーまで見る

    次に学ぶなら、ブラウザの Network タブで実際の通信を1本開き、この記事の観点で分解してみるのが最短です。HTTPは知識として覚えるより、1件の通信を正しく読む練習のほうが実務に直結します。

    参照リンク

    未分類
    API HTTP Web ステータスコード ヘッダー リクエスト レスポンス 初心者向け
    よかったらシェアしてね！
    • URLをコピーしました！
    • URLをコピーしました！
    目次