パスパラメータを一言でいうと
パスパラメータは
「URL の一部として書かれる“ID などの変わる部分”」
です。
/users/1 の 1/products/123/reviews の 123
みたいに、
「どのリソース（どの一件）なのかを特定するための値」 を
URL のパスの中に埋め込んだものがパスパラメータです。
URL の中でパスパラメータがいる場所
具体例で分解してみる
次の URL を見てください。
https://example.com/users/10
ここで
https://example.com がホスト/users/10 がパス
この /users/10 のうち、
/users … ユーザーという“集合”10 … その中の「ID=10 のユーザー」
という意味になります。
この「10」の部分がパスパラメータです。
URL の形としては、よくこう表現します。
/ users / {id}
{id} のところに、1 や 10 や 999 が入るイメージです。
パスパラメータの役割：リソースを一意に特定する
「どの一件の話をしているか」を表す
REST 的な考え方では、
URL のパスは「リソース（資源）」を表します。
/users
→ ユーザーの集合
/users/10
→ その集合の中の「ID=10 のユーザーという 1 件」
この「10」のように、
「値が変わると“別のもの”になる」情報 を
パスパラメータとして表現します。
ユーザー ID
商品 ID
注文 ID
など、「その一件を指すキー」になるものは、
パスパラメータにするのが自然です。
クエリパラメータとの違い
/users/10
→ 「ID=10 のユーザー」という“1 件そのもの”
/users?active=true
→ 「ユーザー集合のうち、有効なものだけ」という“条件付きの集合”
パスパラメータは「どれか 1 件（または階層上の位置）」を指す。
クエリパラメータは「どういう条件で見るか」を指す。
この役割分担を意識しておくと、
URL 設計がかなりきれいになります。
Java（Spring）でのパスパラメータの扱い方
@PathVariable で受け取る
Spring では、パスパラメータは @PathVariable で受け取ります。
@GetMapping("/users/{id}")
public UserResponse get(@PathVariable Long id) {
var user = userService.find(id);
return UserResponse.from(user);
}
/users/10 にアクセスが来ると、id には 10 が入ります。
ここで大事なのは、
「URL の {id} と、メソッド引数の名前（id）を合わせる」
ということです。
もし名前を変えたいときは、こう書きます。
@GetMapping("/users/{id}")
public UserResponse get(@PathVariable("id") Long userId) {
...
}
("id") で「URL 側の名前」を指定し、userId は Java コード側の変数名、という分担になります。
ネストしたパスパラメータ
例えば「あるユーザーの、ある注文 1 件」を表したいときは、こうなります。
/users/{userId}/orders/{orderId}
Spring ではこう書けます。
@GetMapping("/users/{userId}/orders/{orderId}")
public OrderResponse getOrder(
@PathVariable Long userId,
@PathVariable Long orderId
) {
return orderService.findForUser(userId, orderId);
}
このように、
パスの階層構造とパスパラメータを組み合わせて、
リソース同士の関係を表現する
のが REST らしい URL 設計です。
どんなときにパスパラメータを使うべきか
「その値が変わると“別物”になる」ならパス側へ
例えば、ユーザー API を考えます。
/users/10
→ ID=10 のユーザー
これは、ID が 11 になれば「別のユーザー」ですよね。
こういう「その値が変わると別物になる」ものは、
パスパラメータにするのが自然です。
逆に、
/users?active=true
の active=true は、
「ユーザー集合の“見方（フィルタ条件）”」であって、
「別のリソースそのもの」ではありません。
だから、
ID やコードなど“そのものを特定するキー” → パスパラメータ
検索条件やオプション → クエリパラメータ
という分け方がしっくりきます。
動詞をパスに入れない意識
よくある「やりがち」な例として、
/getUser?id=10/deleteUser?id=10
のように、パスに動詞を入れてしまうパターンがあります。
REST 的には、
/users/10 に対して
GET → 取得
DELETE → 削除
というように、
「何をするか」は HTTP メソッドで表現し、
「何に対してか」はパス（パスパラメータ）で表現する
方がきれいです。
パスパラメータで気をつけたいポイント
型とバリデーションを意識する
パスパラメータは文字列として渡されますが、
Java 側では Long や Integer にマッピングされます。
/users/abc のように、
数字でない値が来た場合は 400 Bad Request になります。
サービス層では、
「その ID のリソースが存在しないときはどうするか？」
もセットで考えます。
404 Not Found を返す
独自のエラーコードを返す
など、
「パスパラメータで指定されたリソースが見つからないときの振る舞い」
も API の一部です。
意味のある名前を付ける
/users/{id} でも動きますが、/users/{userId} のように、
「何の ID か」が分かる名前 にしておくと、
URL を見ただけで理解しやすくなります。
ネストしたときも、
/users/{userId}/orders/{orderId}
のように、id ではなく userId / orderId と書くと、
読み手の負荷がかなり下がります。
初心者向けまとめ：パスパラメータを自分の言葉で説明するなら
あなたの言葉で整理すると、こうなります。
パスパラメータは、/users/{id} の {id} のように、
URL のパスの中に埋め込まれた「変わる部分」で、
ユーザー ID や商品 ID など、
「どの一件のリソースか」を特定するための値 を表す。
クエリパラメータが「条件・オプション」なのに対して、
パスパラメータは「そのもの（リソース）を指すキー」。
Java（Spring）では @PathVariable で受け取り、/users/{userId} → @PathVariable Long userId
のように、
URL とコードを対応させて書いていく。
もしよければ、
「ユーザー」「商品」「注文」を題材にして、/users/{userId}, /products/{productId}, /users/{userId}/orders/{orderId}
みたいな URL を自分でいくつか並べてみて。
それを見ながら「この値が変わると何が変わるのか？」を説明できたら、
パスパラメータはもうちゃんと“自分の道具”になっているはず。