URLはWebの基盤ですが、「なんとなく使っている」という開発者も多いリソース識別子です。URLのどのパーツがどんな役割を持つのか、REST APIのエンドポイント設計でパスとクエリパラメータをどう使い分けるか、またURLに関連するセキュリティの注意点を体系的に整理します。
URLの7つのパーツ
URLは `scheme://userinfo@host:port/path?query#fragment` の形式で構成されます。`scheme`（スキーム）はプロトコルを指定し `https`・`http`・`ftp`・`mailto`・`file` などがあります。`host`（ホスト）はドメイン名またはIPアドレスで、`port` は省略時はスキームのデフォルト（HTTPSなら443）が使われます。`path`（パス）はリソースの場所を示すスラッシュ区切りの階層構造です。`query`（クエリ）は `?` 以降の `key=value` 形式のパラメータで、`&` で複数連結できます。`fragment`（フラグメント）は `#` 以降でページ内の特定位置を指し、サーバーには送信されずブラウザのみが処理します。URL Parser Builderに任意のURLを入力すると各パーツに分解して表示でき、複雑なURLの解析に役立ちます。
パスパラメータ vs クエリパラメータ：REST API設計の判断基準
REST APIを設計する際、「パスに入れるべきか、クエリに入れるべきか」という判断は設計の一貫性に大きく影響します。パスパラメータ（`/users/123`）はリソースを一意に識別する値に使います。ユーザーID・記事ID・カテゴリスラグのように「このリソース」を特定するための識別子が該当します。クエリパラメータ（`/users?role=admin&sort=createdAt`）はリソースに対するフィルタリング・ソート・ページネーション・検索条件に使います。「どのリソース群か」ではなく「どう絞り込むか」の情報です。この原則に従うと、`GET /articles/slug-name`（特定記事の取得）と `GET /articles?tag=css&page=2`（CSSTタグの2ページ目）のように一貫したAPI設計になります。
URLエンコードとパーセントエンコーディング
URLに使えない文字（日本語・スペース・`&`・`=` など）はパーセントエンコーディングで `%XX`（16進数2桁）形式に変換する必要があります。「東京」は `%E6%9D%B1%E4%BA%AC` になります。JavaScriptでは `encodeURIComponent()` でクエリパラメータの値をエンコードし、`encodeURI()` でURL全体をエンコードします。両者の違いは `?`・`=`・`&`・`/` をエンコードするかどうかで、クエリパラメータの値には必ず `encodeURIComponent()` を使います。エンコードを忘れると、日本語を含むクエリパラメータが一部の環境で正しく解釈されなかったり、`&` を含む値がパラメータの区切りとして誤解釈される問題が起きます。URL Encoderで変換結果をリアルタイムに確認できます。
セキュリティ：URLに含めてはいけない情報
URLはブラウザの履歴・サーバーのアクセスログ・Refererヘッダーに記録されるため、機密情報を含めると意図せず漏洩します。認証トークン・APIキー・パスワード・個人を特定できる情報（メールアドレス・電話番号）はURLのパスやクエリに含めてはいけません。特に `?token=xxx` のようにアクセストークンをクエリパラメータで渡すと、ブラウザの履歴やサードパーティ解析ツールに記録されるリスクがあります。セッション識別子はCookieやAuthorizationヘッダーで渡すことが推奨されます。OAuthの認証コードはURLに含まれますが、短命（数分）で一度きりの使い切りにすることで漏洩リスクを限定しています。
まとめ
URLはWebアプリケーションのインターフェースの一部です。パスパラメータでリソースを識別し、クエリパラメータで絞り込みを表現するという原則を守ることで、一貫性があり理解しやすいAPI設計になります。また、URLに機密情報を含めないというセキュリティ原則は見落としやすいため、設計レビュー時に意識的にチェックする習慣をつけましょう。