## What — リンクの実体は「URL を1本埋め込んだ部品」 リンク（HTML の `<a href="URL">`）の実体は、飛び先の **URL を1本埋め込んだだけの部品**。クリックとは「この URL に `GET` リクエストを送れ」という指示で、ブラウザは返ってきた HTML で画面を描き直す。ページ遷移の正体はこの往復の繰り返し。 curl で API を叩くのと仕組みは同じで、違うのは返ってくる中身だけ。 - API を叩く → **JSON**（プログラムが読む用）が返る - リンクを踏む → **HTML**（人間が読む用）が返る Web が「ページからページへ辿れる」のは、文書同士が URL で指し合っているから。リンクはその接続点で、ブラウザは「GET 専用の、結果を綺麗に描くクライアント」でしかない。 ## How — URL はエンドポイントと同じ構造 リンクに埋め込まれた `https://api.github.com/repos/owner/repo/issues?state=open#top` を分解すると、API のエンドポイントと同じ構造になっている。 | 部分 | 名前 | 役割 | | --- | --- | --- | | `https` | スキーム | どの言葉で話すか（http / https） | | `api.github.com` | ホスト | どの機械（サーバー）へ届けるか | | `/repos/owner/repo/issues` | パス | どの資源か | | `?state=open` | クエリ | どう見せてほしいか（絞り込み） | | `#top` | フラグメント | ページ内のどこへジャンプするか（ブラウザ内だけで使い、サーバーには送られない） | リンクが持っているのはこの文字列だけ。だから **GET のエンドポイントは、アドレス欄に URL を貼るだけで叩ける**。JSON が生のまま表示され、動作確認の最短手段になる。 ## 落とし穴 **① リンクからは GET しか送れない。** POST や DELETE を送るにはフォームか JavaScript が要る。これは制限ではなく安全装置で、「リンクを踏んだだけでデータが消える」ことを防いでいる。逆に言えば、削除処理を GET で作ると、その安全装置を自分で壊すことになる（クローラや先読みに踏まれて消える）。 **② クエリに秘密を載せない。** `?` 以降は URL の一部なので、ブラウザ履歴・アクセスログ・リンク元情報（Referer）に平文で残る。パスワードやトークンはヘッダかボディで送る。 ## 関連 - [[API]] — API まわりの地図。窓口という考え方もここに - [[HTTPリクエストの流れ]] — GET を送った後、裏で走る DNS → TCP → TLS → HTTP - [[エンドポイント]] — `?` より前（メソッド＋パス）の読み方