HTTPリクエストの構造
What — リクエストは4点セット
HTTP リクエストの実体は、回線を流れるただのテキスト。メソッド・パス・ヘッダ・ボディの4部品でできていて、この4つの名前がわかればどんなリクエストも読める。
| 部品 | 役割 | 例 |
|---|---|---|
| メソッド | 何をしたいか | GET：取得 / POST：作成 / PUT・PATCH：更新 / DELETE：削除 |
| パス | どの資源に対してか | /users/42 ＝ 42番のユーザー |
| ヘッダ | メタ情報（データの取り扱い説明） | Authorization（認証）、Content-Type（データ形式） |
| ボディ | 渡すデータ本体 | GET では空。POST / PUT で使う |
実物 — POST リクエストの生テキスト
ユーザーを新規作成する POST リクエストは、実際にはこのテキストが回線を流れている。
POST /users HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGci...
Content-Type: application/json
{"name": "imutaro", "role": "engineer"}
- 1行目：メソッド（POST＝作成）＋パス（
/users） - 2〜4行目：ヘッダ（宛先・名乗り・データ形式）
- 空行を1つ挟んでボディ。ヘッダとボディの境界はこの空行だけ
GET は「取得」なので渡すデータがなく、ボディごと消えて1行目＋ヘッダだけになる。
GET /users/42 HTTP/1.1
Host: api.example.com
Accept: application/json
なぜヘッダ（メタ情報）が要るのか
ボディ＝データそのもの、ヘッダ＝そのデータの「取り扱い説明」。{"name": "imutaro"} だけ届いても、サーバーはそれが JSON かどうか（Content-Type）も、誰の操作か（Authorization）も判断できない。
しかも HTTP はステートレス＝サーバーは前回の注文を覚えていない。だから「私は誰で、どんな形式で送るか」を毎回の注文票に全部書く必要があり、その置き場所がヘッダ。
関連
- HTTPレスポンスの構造 — この注文への返答側の3点セット
- HTTPリクエストの流れ — このテキストが回線を流れるまでの全工程
- curl — この4部品をオプションで組み立てるコマンド
- API — API まわりの地図
Table of contents