ヘッダーを一言でいうと
HTTP のヘッダーは
「リクエストやレスポンスにくっついてくる“メタ情報（付加情報）”」です。
本体（ボディ）が「中身」だとしたら、
ヘッダーは「この中身は何なのか」「どう扱ってほしいのか」を伝える“説明書”です。
Java で Web アプリを書くとき、ヘッダーを理解しているかどうかで、API 設計の解像度がかなり変わります。
HTTP メッセージの中でのヘッダーの位置づけ
リクエストとレスポンスの構造の中のヘッダー
HTTP メッセージは、大きく分けて
「スタートライン」「ヘッダー」「空行」「ボディ」
という構造になっています。
リクエストなら
GET /users HTTP/1.1（スタートライン）Host: example.com（ヘッダー）User-Agent: ...（ヘッダー）
空行
ボディ（通常 GET ではなし）
レスポンスなら
HTTP/1.1 200 OK（ステータスライン）Content-Type: application/json（ヘッダー）Content-Length: 123（ヘッダー）
空行{"id":1,"name":"Alice"}（ボディ）
というイメージです。
ここでのポイントは、
ヘッダーは「キー: 値」のペアがずらっと並んでいて、
ボディの中身や扱い方、通信の条件などを説明している、ということです。
ヘッダーの役割その1：ボディの“中身の説明”をする
Content-Type で「何のデータか」を伝える
一番分かりやすいのが Content-Type ヘッダーです。
Content-Type: text/html
なら「これは HTML ですよ」。Content-Type: application/json
なら「これは JSON ですよ」。
ブラウザやクライアントは、この情報を見て
「HTML としてレンダリングするのか」
「JSON としてパースするのか」
を判断します。
Java（Spring）では、コントローラで @RestController を使うと、
返り値のオブジェクトを JSON にシリアライズし、
レスポンスヘッダーに自動で Content-Type: application/json を付けてくれます。
逆に、クライアントとして JSON を送るときは、
POST /api/users HTTP/1.1
Content-Type: application/json
{"name":"Alice"}
のように、
「ボディは JSON ですよ」とヘッダーで宣言する必要があります。
ここを間違えると、サーバー側が正しくパースできずに 400 エラーになったりします。
Content-Length で「どれくらいの長さか」を伝える
Content-Length は、ボディのバイト数を表します。
クライアントやサーバーは、この値を見て
「ここまで読めばボディが終わりだな」と判断します。
通常はフレームワークが自動で付けてくれるので、
Java コードで直接意識することは少ないですが、
「ヘッダーでボディの情報を説明している一例」として押さえておくとよいです。
ヘッダーの役割その2：クライアントやユーザーの情報を伝える
User-Agent で「誰がアクセスしているか」のヒントを出す
User-Agent ヘッダーには、
「どんなブラウザ・クライアントからのアクセスか」が入ります。
Chrome
Safari
スマホアプリ
Java の HTTP クライアント
など、クライアントの種類によって値が変わります。
サーバー側は、これを参考にして
「古いブラウザ向けにはこう返そう」
「特定クライアントのバグ回避をしよう」
といった対応をすることもあります。
Java で外部 API を叩くときに、
自分で User-Agent を設定しておくと、
相手側のログに「どのシステムから来たか」が分かりやすくなります。
Accept で「どんな形式で欲しいか」を伝える
Accept ヘッダーは、
「レスポンスはこの形式で返してほしい」という希望を伝えます。
Accept: application/json
なら「JSON で返してほしい」。Accept: text/html
なら「HTML で返してほしい」。
サーバー側は、
クライアントの Accept を見て、
対応できる形式の中から最適なものを選びます（コンテンツネゴシエーション）。
Spring MVC でも、produces = "application/json" のように指定しておくと、Accept に応じたレスポンス形式を制御できます。
ヘッダーの役割その3：認証・セキュリティ・制御情報
Authorization で「誰なのか」を証明する
ログイン済みのユーザーとして API を叩くとき、Authorization ヘッダーがよく使われます。
例えば、JWT を使う場合は
Authorization: Bearer <token>
のような形になります。
サーバー側（Java）は、このヘッダーを読み取り、
トークンを検証して「このリクエストは誰としての操作か」を判断します。
Spring Security を使うと、
このあたりの処理をフレームワークがよしなにやってくれますが、
「認証情報はヘッダーで渡す」という感覚は持っておくとよいです。
Cookie もヘッダーでやり取りされる
ブラウザの Cookie も、実はヘッダーでやり取りされています。
サーバー → ブラウザSet-Cookie: sessionId=xxxx; Path=/; HttpOnly
ブラウザ → サーバーCookie: sessionId=xxxx
Java のサーバー側では、
この Cookie を読み取ってセッションを特定し、
「このリクエストはどのユーザーの継続中の操作か」を判断します。
Cookie 自体はブラウザ側の仕組みですが、
HTTP 的には「ヘッダーで状態をやり取りしている」と理解しておくとスッキリします。
ヘッダーの役割その4：キャッシュや通信の制御
Cache-Control で「どれくらいキャッシュしていいか」を伝える
Cache-Control ヘッダーは、
レスポンスをどれくらいキャッシュしてよいかを指示します。
Cache-Control: no-store
なら「キャッシュしないで」。Cache-Control: max-age=60
なら「60 秒間はキャッシュしてよい」。
ブラウザや中継サーバーは、この指示に従って
レスポンスを保存したり、再利用したりします。
API のレスポンスでも、
「めったに変わらないマスタデータ」はキャッシュを長めに、
「頻繁に変わるデータ」はキャッシュしない、
といった制御をヘッダーで行えます。
CORS（Access-Control-Allow-*）もヘッダーで制御する
フロントエンドとバックエンドが別オリジンのときに出てくる CORS も、
実はヘッダーで制御されています。
サーバー側が
Access-Control-Allow-Origin: https://example.com
のようなヘッダーを返すことで、
「このオリジンからのブラウザ実行の JavaScript からのアクセスを許可する」
という意思表示をします。
Spring では、@CrossOrigin や設定クラスで
これらのヘッダーを自動で付けるようにできますが、
「CORS も結局はヘッダーの話」と知っておくと、エラーの意味が読みやすくなります。
Java 開発者視点での「ヘッダーの押さえどころ」
まずはこのあたりを自分の言葉で説明できると強い
リクエスト側で意識するヘッダーの例としては、Content-Type（送るデータの形式）Authorization（認証情報）Accept（欲しいレスポンス形式）
レスポンス側で意識するヘッダーの例としては、Content-Type（返すデータの形式）Set-Cookie（セッションなど）Cache-Control（キャッシュ方針）
あたりを、自分の言葉で説明できるとかなり実戦的です。
Spring を使うと、多くのヘッダーは自動で付けてくれますが、
「なぜこのヘッダーが必要なのか」「何を意味しているのか」を理解していると、
トラブルシュートや設計のときに一段深く考えられるようになります。
初心者向けまとめ：ヘッダーの役割を自分の言葉で説明するなら
あなたの言葉で整理すると、こうなります。
HTTP ヘッダーは、
リクエストやレスポンスにくっついてくる「メタ情報」で、
ボディの中身の種類（Content-Type）、
クライアントやユーザーの情報（User-Agent, Authorization）、
キャッシュや CORS などの制御情報（Cache-Control, Access-Control-Allow-Origin）
といった「どう扱ってほしいか」「誰から来たか」を伝える“説明書”の役割を持つ。
Java（Spring）では、
多くはフレームワークが自動で付けてくれるが、Content-Type や Authorization、Cookie などの意味を理解しておくと、
API 設計やトラブル対応のときに一段深く考えられるようになる。
もしよければ、
今あなたが作りたい API を一つ決めて、
「この API のリクエストとレスポンスには、どんなヘッダーが付くべきか？」
を一緒に書き出してみよう。
そこを自分で設計できるようになったとき、ヘッダーはもう“勝手に付いてくる謎の文字列”ではなく、“あなたがコントロールする設計要素”になっているはず。