リクエスト / レスポンスを一言でいうと
HTTP の世界は、ものすごく乱暴に言うと「お願い」と「返事」だけでできています。
ブラウザやアプリがサーバーに送る「お願い」がリクエスト、
サーバーがそれに対して返す「返事」がレスポンスです。
Java で Web アプリを書くというのは、
「どんなリクエストが来たら、どんなレスポンスを返すか」をコードで表現することだと思ってください。
リクエストの中身を分解してみる
リクエストライン（1 行目）
まずは典型的なリクエストを眺めてみます。
GET /users?id=1 HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 ...
Accept: text/html
一行目は「リクエストライン」と呼ばれます。
ここには、メソッド、パス、HTTP バージョンが書かれています。
メソッドは「何をしたいか」を表す動詞です。
GET は「取得したい」、POST は「作りたい」、PUT は「更新したい」、DELETE は「削除したい」といった意味を持ちます。
パスは「どのリソースに対してか」を表します。
上の例だと /users がパスで、?id=1 はクエリパラメータです。
HTTP バージョンは、今はだいたい HTTP/1.1 か HTTP/2 ですが、初心者のうちは「プロトコルのバージョンが書いてある」くらいの理解で十分です。
ヘッダ
リクエストラインの下には、ヘッダが続きます。
Host は「どのホスト名に対するリクエストか」。User-Agent は「どんなクライアント（ブラウザ）から来ているか」。Accept は「どんな種類のレスポンスを受け取りたいか」。
こういった「追加情報」がヘッダに詰まっています。
Java（Spring）では、これらを @RequestHeader で受け取ったり、フレームワークに任せたりできます。
ボディ（必要なときだけ）
GET のような「ただ取得するだけ」のリクエストには、通常ボディは付きません。
一方、フォーム送信や JSON を送る POST などでは、ボディに本体データが入ります。
例えば、ユーザー登録の JSON を送るときはこんな感じです。
POST /users HTTP/1.1
Host: example.com
Content-Type: application/json
{"name":"Alice","email":"alice@example.com"}
Java（Spring）では、このボディを @RequestBody で受け取ります。
@PostMapping("/users")
public UserResponse create(@RequestBody UserRequest request) {
...
}
ここで大事なのは、「リクエストは 1 本のテキストの塊だが、論理的には 3 つに分かれている」とイメージできることです。
一行目（メソッド＋パス）、ヘッダ、ボディ。この 3 つを意識すると、HTTP が一気に読みやすくなります。
レスポンスの中身を分解してみる
ステータスライン（1 行目）
次はレスポンスです。
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 1234
<html>...</html>
一行目は「ステータスライン」と呼ばれます。
ここには、HTTP バージョン、ステータスコード、ステータスメッセージが書かれています。
ステータスコードは特に重要です。
200 は「成功」、
400 は「クライアントのリクエストがおかしい」、
404 は「その URL のリソースは見つからない」、
500 は「サーバー内部でエラーが起きた」、
といった意味を持ちます。
Java では、Spring がデフォルトで 200 を返してくれますが、ResponseEntity を使えば自分でステータスコードを指定できます。
@GetMapping("/users/{id}")
public ResponseEntity<UserResponse> get(@PathVariable Long id) {
return userService.find(id)
.map(ResponseEntity::ok)
.orElseGet(() -> ResponseEntity.notFound().build());
}
ここでは、見つかったときは 200、見つからなかったときは 404 を返しています。
「どんな状況でどのステータスコードを返すか」を設計するのも、バックエンドの大事な仕事です。
レスポンスヘッダ
ステータスラインの下には、レスポンスヘッダが続きます。
Content-Type は「ボディの中身の種類」を表します。
HTML なら text/html、JSON なら application/json、画像なら image/png などです。
Content-Length は「ボディのバイト数」です。
他にも、キャッシュ制御、クッキー設定、CORS 関連など、多くの情報がヘッダでやり取りされます。
Spring は、戻り値の型やアノテーションから Content-Type を自動で決めてくれます。
例えば、@RestController でオブジェクトを返すと、自動的に JSON にシリアライズされ、application/json が付きます。
レスポンスボディ
空行のあとに続くのがボディです。
ここに、ブラウザが最終的に欲しい中身が入っています。
HTML を返す場合は、テンプレートエンジンで組み立てた HTML が入ります。
JSON を返す API の場合は、シリアライズされた JSON が入ります。
Java のコードから見ると、
「メソッドの戻り値」や「テンプレート名」が、
最終的にレスポンスボディに変換されてブラウザに届いている、
というイメージです。
リクエストとレスポンスの「対応関係」を意識する
1 本のリクエストに対して 1 本のレスポンス
HTTP の基本ルールはとてもシンプルで、
「1 本のリクエストに対して、必ず 1 本のレスポンスが返る」です。
ブラウザが GET /users を送ったら、
サーバーは必ず何かしらのレスポンスを返します。
成功なら 200 と HTML／JSON、
失敗なら 4xx や 5xx とエラーメッセージ。
Java の Web アプリを書くときは、
「このエンドポイントにリクエストが来たら、どんなレスポンスを返すべきか」
を常にセットで考えます。
例えば、ユーザー登録 API なら、
成功時は 201 Created と作成されたユーザー情報、
バリデーションエラーなら 400 Bad Request とエラー内容、
権限がなければ 403 Forbidden、
といった具合に「状況ごとのレスポンス」を設計します。
リクエストの情報をどう使ってレスポンスを決めるか
リクエストには、パス、クエリパラメータ、ヘッダ、ボディなど、たくさんの情報が入っています。
バックエンドは、それらを使って「どんな処理をするか」「どんなレスポンスを返すか」を決めます。
例えば、検索 API なら、
パス /users
クエリパラメータ ?name=Alice&page=2
ヘッダの認証情報
などを見て、
「このユーザーは検索してよい人か」
「どの条件で検索するか」
「何件目から何件目まで返すか」
を決め、
その結果を JSON にしてレスポンスボディに詰めます。
この「リクエストのどの情報を、どの層で使うか」を意識して設計すると、
Controller／Service／Repository の役割分担もきれいになります。
Java コードとリクエスト / レスポンスの対応を結びつける
Spring MVC のメソッドは「リクエストに対するハンドラ」
Spring MVC では、@GetMapping や @PostMapping を付けたメソッドが、
特定のリクエストを処理する「ハンドラ」になります。
@GetMapping("/users")
public List<UserResponse> list() { ... }
@PostMapping("/users")
public UserResponse create(@RequestBody UserRequest request) { ... }
GET /users が来たら list が呼ばれ、POST /users が来たら create が呼ばれる、という対応です。
メソッドの引数には、
パスパラメータ（@PathVariable）、
クエリパラメータ（@RequestParam）、
ボディ（@RequestBody）、
ヘッダ（@RequestHeader）
などをマッピングできます。
メソッドの戻り値は、
HTML を返す場合はテンプレート名、
JSON を返す場合はオブジェクト、
といった形でレスポンスボディに変換されます。
つまり、
「リクエストのどの部分を引数として受け取り、
どんなオブジェクトを戻り値として返すか」
を決めることが、
そのまま「リクエスト / レスポンスの設計」になっています。
初心者がまず押さえるべきリクエスト / レスポンスのイメージ
最後に、あなたの言葉で整理するとこうなります。
リクエストは、
メソッド（GET/POST など）、
パス（URL）、
ヘッダ、
ボディ（必要なら）
からなる「サーバーへのお願いの手紙」。
レスポンスは、
ステータスコード（200/404/500 など）、
ヘッダ、
ボディ（HTML や JSON）
からなる「サーバーからの返事の手紙」。
Java で Web アプリを書くというのは、
「どんなリクエストが来たときに、どんなレスポンスを返すか」を
Controller／Service／Repository を使って設計し、コードに落とし込むこと。
もしよければ、ブラウザの開発者ツールを開いて、
今あなたがよく使っているサイトのリクエストとレスポンスを一緒に眺めてみよう。
「この画面の裏で、どんな手紙のやり取りが行われているか」を読めるようになると、
HTTP も Java の Web 開発も、一気に“自分ごと”になってくるから。