Java | Web 基礎・HTTP・REST：HTTP 詳細 － ボディの役割

Java Java
スポンサーリンク

ボディを一言でいうと

HTTP のボディは
「実際にやり取りしたい“中身そのもの”が入る場所」
です。

ヘッダーが「説明書」だとしたら、
ボディは「商品そのもの」。
ユーザー情報の JSON、HTML のページ、画像ファイル、フォームの内容など、
本当に送りたいデータ本体 がここに入ります。

HTTP メッセージの中でのボディの位置づけ

リクエストとレスポンスの構造

HTTP メッセージは、ざっくりこういう構造でした。

  • スタートライン（リクエストライン／ステータスライン）
  • ヘッダー
  • 空行
  • ボディ

リクエストの例です。

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

{"name":"Alice","email":"alice@example.com"}
HTTP

上の JSON 部分が「ボディ」です。

レスポンスならこうです。

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

{"id":1,"name":"Alice","email":"alice@example.com"}
HTTP

ここでも、最後の JSON がボディです。

ボディは必須ではありません。
GET のように「読むだけ」のリクエストでは、ボディがないことも多いです。

ボディの役割その1：サーバーに「データを渡す」

典型例：ユーザー登録（POST）

ユーザー登録を考えてみましょう。
フォームに入力した内容をサーバーに送りたいとき、
その「入力内容」がボディに入ります。

POST /api/users HTTP/1.1
Content-Type: application/json

{
  "name": "Alice",
  "email": "alice@example.com",
  "password": "secret"
}
HTTP

意味は
「この JSON の内容で新しいユーザーを作ってください」
です。

Java（Spring）側では、こう受け取ります。

@PostMapping("/api/users")
public UserResponse create(@RequestBody UserRequest request) {
    var user = userService.register(request);
    return UserResponse.from(user);
}
Java

ここで @RequestBody が、
「HTTP のボディに入っている JSON を UserRequest にマッピングしてね」
という意味です。

ポイント：
“複雑なデータ”や“機密情報”は、URL ではなくボディに載せる。
クエリパラメータにパスワードを載せるのは絶対にやめましょう。

ボディの役割その2：クライアントに「データを返す」

典型例：JSON を返す API

REST API では、レスポンスボディに JSON を入れて返すのが定番です。

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

{
  "id": 1,
  "name": "Alice",
  "email": "alice@example.com"
}
HTTP

Java（Spring）では、
コントローラの返り値にオブジェクトを返すと、
それを JSON に変換してボディに詰めてくれます。

@GetMapping("/api/users/{id}")
public UserResponse get(@PathVariable Long id) {
    var user = userService.find(id);
    return UserResponse.from(user);
}
Java

ここで UserResponse がそのままボディの中身（JSON）になります。

HTML やファイルもボディに入る

ブラウザで普通の Web ページを開くときも、
HTML はレスポンスボディに入っています。

HTTP/1.1 200 OK
Content-Type: text/html

<!DOCTYPE html>
<html>...</html>
HTTP

画像や PDF をダウンロードするときも、
そのバイナリデータがボディに入ります。

ボディは「形式を問わず、データ本体を入れる箱」
だとイメージしておくとよいです。

ボディとヘッダーの関係

「中身」と「中身の説明」

ボディ：
実際のデータ本体（JSON、HTML、画像、フォームデータなど）

ヘッダー：
そのデータの説明（Content-Type, Content-Length など）

例えば、JSON を返すときはこうです。

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

{"id":1,"name":"Alice","email":"alice@example.com"}
HTTP

Content-Type を見て、
クライアントは「これは JSON だな」と理解し、
ボディを JSON としてパースします。

重要：
ボディだけあっても、ヘッダーで「これは何か」を伝えないと、
相手は正しく解釈できない。
逆に、ヘッダーだけあっても、中身（ボディ）がなければ意味がない。

どのメソッドでボディを使うことが多いか

よくボディを持つメソッド

POST：
新規作成や処理実行のためのデータをボディに載せることが多い。

PUT：
リソースの「新しい完全な状態」をボディに載せる。

PATCH：
部分更新したいフィールドをボディに載せる。

あまりボディを使わないメソッド

GET：
基本はボディなし（条件はクエリパラメータ）。
※仕様上はボディを付けてもよいが、実務ではほぼ使わない。

DELETE：
対象はパスパラメータで特定するので、ボディなしが多い。

設計の目安：
“何かを送ってサーバーに処理してほしい”ときはボディを使う。
“ただ見たいだけ”の GET は、ボディではなくパスやクエリで表現する。

Java 開発者視点での「ボディの押さえどころ」

リクエストボディ：@RequestBody と DTO

クライアントから JSON を受け取るときは、
@RequestBody と DTO クラスの組み合わせが基本パターンです。

public class UserRequest {
    private String name;
    private String email;
    // getter / setter
}
Java
@PostMapping("/api/users")
public UserResponse create(@RequestBody UserRequest request) {
    ...
}
Java

ここで大事なのは、
「ボディの構造（JSON）を、自分で設計する」
という意識です。

どんなフィールドを持たせるか
必須項目は何か
クライアントに見せたくない内部情報は入れていないか

ボディの設計は、そのまま「API の顔」になります。

レスポンスボディ：返り値とシリアライズ

レスポンスボディは、
コントローラの返り値のクラス設計に直結します。

エンティティをそのまま返すのではなく、
レスポンス専用の DTO（UserResponse など）を用意する
のが実務ではよくあるパターンです。

これにより、
「外部に見せる項目」と「内部のドメインモデル」を分離できます。

初心者向けまとめ：ボディの役割を自分の言葉で説明するなら

あなたの言葉で整理すると、こうなります。

HTTP のボディは、
リクエストやレスポンスの「中身そのもの」が入る場所で、
JSON・HTML・画像・フォームデータなど、
本当にやり取りしたいデータ本体を運ぶ役割を持つ。

ヘッダーはその中身の説明（Content-Type など）、
ボディは中身そのもの。

Java（Spring）では、
リクエストボディは @RequestBody で DTO にマッピングし、
レスポンスボディは返り値のオブジェクトを JSON などにシリアライズして返す。

もしよければ、
「ユーザー登録 API」と「ユーザー取得 API」を題材にして、
それぞれのリクエストボディ・レスポンスボディの JSON を
自分の手で書き出してみよう。
その形を自分で説明できるようになったとき、ボディはもう“黒い箱”ではなく、“あなたがデザインするデータ”になっているはず。

スポンサーリンク
タイトルとURLをコピーしました