Java | Web 基礎・HTTP・REST：HTTP 基礎 － GET の役割

GET を一言でいうと

GET は
「サーバーのデータを“読むだけ”のメソッド」
です。

「この URL の内容を見せて」「このデータを教えて」というときに使います。
サーバー側の状態を変えない（書き換えない）ことが大前提です。

GET の基本的な役割

「取得専用」のメソッド

典型的な GET リクエストはこうです。

GET /users/1 HTTP/1.1
Host: example.com

GET /users/1 HTTP/1.1
Host: example.com

意味は「ID=1 のユーザー情報を見せて」です。
サーバーは、DB からユーザー情報を読み取り、HTML や JSON にして返します。

ここで重要なのは、
GET を呼んだことで「ユーザーが増える」「削除される」「更新される」といった
状態の変化が起きてはいけないということです。

Java（Spring）での GET の書き方

Spring では、GET は @GetMapping で表現します。

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

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

このメソッドは、
「ID を受け取って、ユーザー情報を返すだけ」です。
ここで登録や更新、削除をしてはいけません。

GET の「副作用なし」がなぜそんなに大事なのか

副作用がない＝何回呼んでも結果が変わらない

GET は「副作用がない（サーバーの状態を変えない）」ことが前提です。
これをもう一歩踏み込んで言うと、

同じ URL に対する GET は、
何回呼んでもサーバー側の状態は変わらないし、
基本的には同じ結果が返ってくる

という性質を持ちます。

これを「安全（safe）」と呼びます。

キャッシュやブラウザの最適化に効いてくる

GET が「読むだけ」だと分かっているからこそ、
ブラウザやプロキシ、CDN は GET の結果をキャッシュできます。

例えば、

同じ画像の URL
同じ CSS の URL
同じ API の GET

に対して、
毎回サーバーに取りに行くのではなく、
一度取った結果をしばらく再利用できます。

もし GET で「データを削除する」「登録する」といった副作用を持たせてしまうと、
キャッシュや再試行（リトライ）によって、
意図しないタイミングで処理が何度も走る危険があります。

だから、
「GET は読むだけ」
というルールは、
性能と安全性の両方に直結する、とても重要な約束事です。

GET とクエリパラメータ

URL に条件を付けて「こういう条件で教えて」

GET では、URL の後ろにクエリパラメータを付けて条件を指定します。

GET /users?name=Alice&page=2 HTTP/1.1

GET /users?name=Alice&page=2 HTTP/1.1

意味は「名前が Alice のユーザーを、2 ページ目で教えて」です。

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

@GetMapping("/users")
public List<UserResponse> search(
        @RequestParam String name,
        @RequestParam int page
) {
    return userService.search(name, page);
}

@GetMapping("/users")
public List<UserResponse> search(
        @RequestParam String name,
        @RequestParam int page
) {
    return userService.search(name, page);
}

ここでもやっていることは「検索して返すだけ」です。
検索結果を返すのは OK ですが、
この GET を呼んだことで DB の中身が変わるようなことはしてはいけません。

GET でやってはいけないこと

1. 削除や更新を GET でやる

例えば、こんな URL を見たことがあるかもしれません。

GET /deleteUser?id=1

GET /deleteUser?id=1

技術的には動きますが、設計としては完全にアウトです。
理由はシンプルで、

GET は「読むだけ」のはずなのに、
この GET を呼ぶと「削除」という強い副作用が起きてしまう

からです。

検索エンジンのクローラや、
ブラウザの「リンク先を事前に読み込む」機能などが
この URL を勝手に叩いたら、
ユーザーが意図していないのにデータが消えてしまいます。

削除は必ず DELETE、
更新は PUT や PATCH、
新規作成は POST、
というように、
「状態を変える操作は GET 以外でやる」
というルールを守ることがとても大事です。

2. 機密情報を GET のクエリに載せる

GET のクエリパラメータは、
URL にそのまま見えます。

ブラウザの履歴
アクセスログ
プロキシのログ

などに残りやすいので、
パスワードやクレジットカード番号などの機密情報を
クエリに載せるのは NG です。

ログイン処理などは、
POST のボディに載せるのが基本です。

Java 開発者視点での GET の使いどころ

画面表示・一覧・詳細・検索はまず GET を疑え

「この機能、HTTP 的には何メソッドだろう？」と迷ったら、
まずこう自問してみてください。

「これはサーバーの状態を変えるか？
それとも、ただ情報を見たいだけか？」

ただ見たいだけなら、ほぼ確実に GET です。

一覧表示
詳細表示
検索結果表示
ダウンロード（ただのファイル配布）

こういったものは、基本すべて GET で設計します。

Spring でのパターンを体に染み込ませる

よくあるパターンは、こんな感じです。

// 一覧
@GetMapping("/users")
public List<UserResponse> list() { ... }

// 詳細
@GetMapping("/users/{id}")
public UserResponse get(@PathVariable Long id) { ... }

// 検索
@GetMapping("/users/search")
public List<UserResponse> search(@RequestParam String keyword) { ... }

// 一覧
@GetMapping("/users")
public List<UserResponse> list() { ... }

// 詳細
@GetMapping("/users/{id}")
public UserResponse get(@PathVariable Long id) { ... }

// 検索
@GetMapping("/users/search")
public List<UserResponse> search(@RequestParam String keyword) { ... }

これが自然に書けるようになると、
「GET の役割」が体に入ってきた証拠です。

初心者向けまとめ：GET を自分の言葉で説明するなら

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

GET は、
「この URL の情報を見せて」とサーバーにお願いするためのメソッドで、
サーバー側の状態を変えない“読み取り専用”の操作。

一覧表示・詳細表示・検索・ダウンロードなど、
「見るだけ」の機能はすべて GET で設計する。

副作用がないからこそ、
キャッシュや再試行が安全に行え、
ブラウザやネットワーク機器が最適化しやすい。
逆に、削除や更新を GET でやると、
予期せぬタイミングでデータが変わる危険な設計になる。

もしよければ、
今頭に浮かんでいる機能を一つ挙げて、
「これは本当に GET でいいのか？ 状態は変わらないか？」
を一緒にチェックしてみよう。
その問いを自分で回せるようになると、HTTP メソッド設計の精度が一気に上がるから。