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