リンクの原理
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
- エンドポイント —
?より前（メソッド＋パス）の読み方
Table of contents