概要

HTTPを実務で読めるようになるには、まずリクエストとレスポンスの構造を分解して理解するのが近道です。メソッド、パス、ヘッダー、ボディ、ステータスコードの役割を整理すると、API仕様書やDevToolsの画面が読みやすくなります。

HTTPメッセージの全体像

HTTP通信は「リクエストメッセージ」と「レスポンスメッセージ」の交換です。それぞれに開始行、ヘッダー、必要に応じてボディがあります。

HTTPを細かく見ると、クライアントが送るリクエストと、サーバーが返すレスポンスは、どちらもある程度決まった構造を持っています。

ざっくりしたイメージは次の通りです。

この構造を知っていると、次のような場面で役立ちます。

• API仕様書を読む
• ブラウザのNetworkタブを見る
• curl -i の結果を理解する
• サーバーログやプロキシログを読む
• 400系や500系エラーの原因を絞り込む

リクエストの構造

リクエストは「何をしたいか」をサーバーへ伝えるメッセージです。特に重要なのは、メソッド、対象パス、ヘッダー、ボディです。

リクエストは主に次の要素で構成されます。

• 開始行（メソッド、パス、HTTPバージョン）
• ヘッダー
• ボディ（必要な場合のみ含まれます）

簡略化した例です。

GET /products/1 HTTP/1.1
Host: example.com
Accept: application/json
User-Agent: curl/8.0

この例では、クライアントは /products/1 を取得したいと伝えています。

開始行の見方

開始行を見ると、そのリクエストが「何を」「どうしたいか」を最短で把握できます。

開始行は次の3つで構成されます。

たとえば次の開始行からは、「/orders に対して新しいデータを送る処理」が想像できます。

POST /orders HTTP/1.1

ヘッダーの役割

ヘッダーは、本文そのものではなく、通信条件や追加情報を伝えるために使われます。

よく使うリクエストヘッダーの例を挙げます。

たとえばJSONを送るPOSTリクエストでは、Content-Type が重要です。Content-Type が適切でないと、サーバー側が本文を正しく解釈できないことがあります。

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

{"name":"Keyboard","price":5000}

ボディがある場合とない場合

HTTPリクエストには常にボディがあるわけではありません。取得系はボディなし、作成・更新系はボディあり、という形がよくあります。

代表的には次の傾向があります。

ただし、これは「よくある形」であり、実装やAPI設計方針によって差はあります。

レスポンスの構造

レスポンスは、サーバーが「どう処理したか」と「何を返すか」を表すメッセージです。特にステータスコードとレスポンスヘッダーが重要です。

レスポンスは主に次の要素で構成されます。

• ステータス行
• ヘッダー
• ボディ（必要な場合のみ含まれます）

簡略化した例です。

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

{"id":1,"name":"Sample Product"}

ステータス行の見方

ステータス行を見ると、サーバーがそのリクエストをどう処理したかを素早く把握できます。

代表的なステータスコードの例です。

レスポンスヘッダーの役割

レスポンスヘッダーは、返ってくるデータの形式やキャッシュ方針、Cookie設定などを伝えます。

よく出会うレスポンスヘッダーの例です。

たとえばログイン成功時には、レスポンスに Set-Cookie が含まれることがあります。この場合、ブラウザはCookieを保存し、以後のリクエストで自動的に送信します。

HTTP/1.1 200 OK
Content-Type: application/json
Set-Cookie: session_id=abc123; HttpOnly; Secure

{"result":"ok"}

レスポンスボディがないケース

成功していても、常にレスポンスボディが返るわけではありません。特に 204 No Content は本文なしが前提です。

削除APIや一部の更新APIでは、処理成功だけを伝えて本文を返さない設計もよくあります。

HTTP/1.1 204 No Content

よく使うヘッダーを最初に覚える

ヘッダーは種類が多いですが、最初は用途の広い少数だけ押さえると実務で困りにくくなります。

最初に優先して覚えておきたいヘッダーです。

• リクエスト側: Host、Accept、Content-Type、Authorization、Cookie
• レスポンス側: Content-Type、Cache-Control、Set-Cookie、Location

この段階では、すべてを暗記する必要はありません。「ヘッダーは通信条件や付加情報を伝える場所」と理解しておくと整理しやすくなります。

具体例で見るHTTPメッセージ

1回のAPI作成リクエストを通しで見ると、リクエストとレスポンスの関係が理解しやすくなります。

商品の作成APIを例にします。

リクエスト例

クライアントはメソッド、送信先、本文形式、認証情報、本文データをまとめて送ります。

POST /products HTTP/1.1
Host: api.example.com
Authorization: Bearer xxxxxx
Content-Type: application/json
Accept: application/json

{
  "name": "Keyboard",
  "price": 5000
}

レスポンス例

サーバーは作成成功を示すステータスと、作成したデータや場所を返します。

HTTP/1.1 201 Created
Content-Type: application/json
Location: /products/101

{
  "id": 101,
  "name": "Keyboard",
  "price": 5000
}

このやり取りから、少なくとも次が読み取れます。

• POST なので作成系の操作
• JSON形式でデータを送っている
• 認証が必要なAPI
• 201 Created なので新規作成成功
• Location に新しいリソース位置がある

DevToolsとcurlで見るポイント

実務では、構造を暗記するより「どこを見ればよいか」を知る方が役立ちます。

{{image:devtools_network_tab}}

ブラウザの開発者ツールや curl では、次の順に見ると効率的です。

1. URL
2. メソッド
3. ステータスコード
4. Content-Type
5. 認証ヘッダーやCookie
6. リクエストボディ
7. レスポンスボディ

curl でヘッダー込みで見る例:

curl -i https://example.com/products/1

JSONを送る例:

curl -i \
  -X POST \
  -H "Content-Type: application/json" \
  -H "Accept: application/json" \
  -d '{"name":"Keyboard","price":5000}' \
  https://api.example.com/products

よくあるつまずき

HTTPの構造を知らないと、エラーの原因が本文なのかヘッダーなのか切り分けにくくなります。

HTTPでは、ヘッダーが原因の不具合が多くあります。本文だけを見て終わらず、ヘッダーも必ず確認するようにすると切り分けがしやすくなります。

まとめ

HTTPのリクエストとレスポンスは、開始行、ヘッダー、ボディという一定の構造で成り立っています。この構造を理解すると、API仕様、DevTools、curl、ログの読み方が一気につながります。

• リクエストは「何をどうしたいか」をサーバーへ伝える
• レスポンスは「どう処理したか」と「何を返すか」を表す
• リクエストではメソッド、パス、ヘッダー、ボディが重要
• レスポンスではステータスコード、ヘッダー、ボディが重要
• Content-Type、Accept、Authorization、Set-Cookie などは実務で特に重要
• エラー時はURL、メソッド、ステータス、ヘッダー、ボディの順に確認すると切り分けやすい