Java | Web 基礎・HTTP・REST：HTTP 詳細 － URL 構造

Java Java
スポンサーリンク

URL を一言でいうと

URL は
「インターネット上の“場所”を指し示す住所」
です。

ブラウザやプログラムは、この URL を手がかりに
「どのサーバーの」「どのサービスの」「どのデータを」
取りに行けばいいかを判断します。

Java で Web アプリを書くとき、
あなたは「自分のアプリの URL 設計」をすることになります。
だから、URL の構造をちゃんと分解して理解しておくのは、かなり大事です。

URL の全体構造を分解してみる

典型的な URL の例

まずは、よくある形を一つ見てみましょう。

https://example.com:8080/users/10?active=true#profile

これをパーツに分解すると、こうなります。

https
example.com
8080
/users/10
?active=true
#profile

それぞれにちゃんと意味があります。

大きく分けると 5 つの部分

ざっくり言うと、URL は次の 5 つに分かれます。

スキーム（プロトコル）
ホスト名（＋ポート番号）
パス
クエリ（クエリパラメータ）
フラグメント（ハッシュ）

この 5 つを「言葉で説明できる」ようになるのがゴールです。

スキーム（プロトコル）：どうやって話すか

http と https の違い

URL の最初にある https:// の部分が「スキーム」です。
「この URL には、どのプロトコルでアクセスするか」を表します。

http://
暗号化なしの HTTP。今はほぼ使われません。

https://
暗号化された HTTP。今の Web ではほぼこれ一択です。

ブラウザは、
https:// を見たら「TLS で暗号化された HTTP で通信しよう」と判断します。

Java（Spring Boot）でアプリを公開するときも、
本番環境では基本的に https:// でアクセスされる前提で考えます。

ホスト名とポート：どのサーバーのどの入口か

ホスト名（ドメイン）

https://example.com:8080/users/10
の example.com がホスト名（ドメイン）です。

これは「どのサーバーか」を表します。

example.com
api.example.com
localhost

など、DNS で IP アドレスに変換される名前です。

ブラウザは、
ホスト名から IP アドレスを調べて、
そのサーバーに接続しに行きます。

ポート番号

example.com:8080 の 8080 がポート番号です。

同じサーバー（同じ IP アドレス）の中で、
「どのアプリケーションに話しかけるか」を区別する番号だと思ってください。

HTTP のデフォルトポートは 80
HTTPS のデフォルトポートは 443

なので、

https://example.com

と書いたときは、
実は内部的には

https://example.com:443

と同じ意味になります。

Java（Spring Boot）をローカルで動かすとき、
http://localhost:8080
にアクセスすることが多いですよね。

これは
「自分の PC（localhost）の 8080 番ポートで待っているアプリに話しかける」
という意味です。

パス：サーバーの中の「どのリソースか」

/users/10 のような部分

https://example.com:8080/users/10
の /users/10 が「パス」です。

これは、
「そのサーバーの中の、どのリソース（資源）にアクセスしたいか」
を表します。

/
トップページ

/users
ユーザーの集合

/users/10
ID=10 のユーザー

/products/123/reviews
ID=123 の商品のレビュー一覧

というように、
パスは「階層構造でリソースを表現する」 のが基本です。

REST とパス設計

Java で REST API を作るとき、
この「パスの設計」がかなり重要になります。

例えば、ユーザー API なら、

GET /api/users
GET /api/users/10
POST /api/users
DELETE /api/users/10

のように、
「名詞（リソース）」をパスで表し、「動詞（操作）」は HTTP メソッドで表す
のが REST らしい設計です。

/getUser /deleteUser のように、
パスに動詞を入れ始めると、
だんだんゴチャゴチャしてきます。

URL のパスは「何を（What）」、
HTTP メソッドは「どうする（Do）」、
と分けて考える癖をつけると、設計が一気にきれいになります。

クエリ（クエリパラメータ）：条件やオプション

?active=true&page=2 の部分

https://example.com/users?active=true&page=2
の ?active=true&page=2 が「クエリ」です。

? のあとに
key=value を & でつないだもの
が並びます。

例えば、

/users?active=true
「有効なユーザーだけ欲しい」

/users?keyword=java&page=2
「java で検索した結果の 2 ページ目が欲しい」

というように、
「同じリソースに対して、条件やオプションを指定する」 のに使います。

パスとクエリの役割分担

パス：
「どのリソースか」
例：/users/10 → ID=10 のユーザー

クエリ：
「そのリソースに対して、どんな条件・オプションか」
例：/users?active=true → ユーザー集合のうち、有効なものだけ

この分担を意識しておくと、
URL 設計がかなりスッキリします。

Java（Spring）では、
パスは @PathVariable、
クエリは @RequestParam
で受け取るのが定番です。

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

@GetMapping("/users")
public List<UserResponse> search(
        @RequestParam(required = false) Boolean active,
        @RequestParam(defaultValue = "1") int page
) { ... }
Java

フラグメント（ハッシュ）：ブラウザ内の位置

#profile の部分

https://example.com/users/10#profile
の #profile が「フラグメント（ハッシュ）」です。

これは、
「ブラウザの中で、ページ内のどの位置を表示するか」
を表すもので、
サーバーには送られません。

例えば、

https://example.com/docs#section3

にアクセスすると、
ブラウザは /docs のページを読み込んだあと、
id="section3" の要素の位置までスクロールします。

Java のバックエンドから見ると、
フラグメントは HTTP リクエストには含まれないので、
基本的に意識しなくて構いません。

Java 開発者視点での「URL 構造」の押さえどころ

1. パスで「リソース」をきれいに表現する

REST API を設計するとき、
パスは「名詞」で、
HTTP メソッドは「動詞」で表現する、
という軸を大事にしてください。

/users
/users/{id}
/users/{id}/orders

のように、
リソースの関係をパスの階層で表すと、
URL を見ただけで「何の話をしているか」が分かります。

2. クエリで「条件・オプション」を表現する

検索条件
ページング（page, size）
ソート（sort）

などは、クエリパラメータで表現するのが自然です。

/users?keyword=alice&page=2&size=20

Java（Spring）では、
@RequestParam で素直に受け取るだけで OK です。

3. ホスト名・ポートは環境ごとに変わる前提で

ローカル：http://localhost:8080
ステージング：https://stg-api.example.com
本番：https://api.example.com

のように、
ホスト名やポートは環境ごとに変わります。

アプリ側では、
「自分は /api/... 以下を担当する」
くらいの意識でいて、
ホスト名やポートは設定ファイルやインフラ側に任せる、
という分担になります。

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

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

URL は、
スキーム（https）
ホスト名（example.com）
ポート（:8080 など、省略されることも多い）
パス（/users/10）
クエリ（?active=true&page=2）
フラグメント（#profile）
からなる「インターネット上の住所」。

パスは「どのリソースか」、
クエリは「どんな条件・オプションか」、
フラグメントは「ページ内のどこを表示するか（サーバーには送られない）」。

Java（Spring）では、
パスを @PathVariable、
クエリを @RequestParam で受け取り、
REST らしい URL 設計をしていく。

もしよければ、
「ユーザー」「商品」「注文」あたりを題材にして、
自分なりの URL 一覧（/users, /users/{id}, /products/{id}/reviews など）を一緒に書き出してみよう。
そこを自分の手で設計できるようになると、URL はもう“暗記するもの”ではなく、“自分でデザインするもの”になってくるから。

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