🌓

【要約と感想】 Webを支える技術 ②URI 編

2023/04/09に公開

https://zenn.dev/rayto312/articles/6c84f7be173f8c
こちらの続きです。

おことわり

以下、あらかじめおことわりしておきます。

  • 「Webを支える技術」について、すべては紹介できませんが、バッサリと端折りつつ、私が面白いと思った部分について感想を交えつつ紹介していこうと思います。
  • すべてが感想的な語り口になってしまうとどうも伝わりにくい気がしたので、書籍に書かれている内容に関しても、あえて私自身が話し手の立場のような口調で書いています。
  • 内容の信憑性に関しては保証出来かねます。

URIとは?

https://gimo.jp/glossary/details/uri.html
URI(Uniform Resource Identifier)とは、つまりはWeb上に存在するリソースを一意に識別できるIDです。
こういうやつです。

http://www.example.com/login/

これはURLでは?URIってURLとは何か違うんじゃないの?と思いますよね。
詳細は後述しますが、結論から言うと、URIはURLと同じものだと思ってしまってよいです。

厳密に言うと、URIというのは「URL」というものと「URN」というものの総称なのです。
もう少し詳しく説明します。

URL、URNとは?

URLは、前述したこういうやつです。URIと同じです。

http://www.example.com/login/

URLは「Uniform Resource Locator」の略ですが、「Locator」は位置を指し示すものを意味します。
上記のURLの例では、Web上に存在する「www.example.com」というホストの「login」というパスに存在するリソース(の場所)を一意に識別しています。
URLをブラウザで指定すればリソースにアクセスできます。

一方で、URNは「Uniform Resource Name」の略で、「Name」からわかるように名前を指し示します。
具体例としてはこういうやつです。(xxxxxxxxxxには数字が入ります)

urn:isbn:xxxxxxxxxx

上記のURLの例では、Web上に存在する「isbn」という名前空間の「xxxxxxxxxx」というIDのリソース(の名前)を一意に識別しています。

URLとURLの違い

元々は、リソースにアクセスするためにURLが使われていましたが、URLにはドメインが変更になるとアクセスできなくなってしまうというデメリットがあります。
そのため、ドメインに依存せず永続的にリソースにアクセスできるようにURNというものが作られました。
しかし、実際にはURLで十分に永続的であり、URNはあまり使われなくなったという悲しい歴史があるようです。
少なくとも、私はURNを使ったことはないですね。。
これは推測ですが、URNがあまり使われなくなったという経緯によって、「URI」をURLとURNの総称ではなく、URLを指す言葉として使っている記事などが存在するのかなと思います。

URIという言葉はあまり見かけないのと、URIと言ってしまうと厳密にはURNも含めた意味に捉えられる可能性もあるので、私自身はURLのことを表現するときには「URL」とした方が良いと思っています。
一方で、本記事では本書にならってこれ以降URIで統一します。

クールなURIは変わらない

「【要約と感想】 Webを支える技術 ①概要・歴史 編」に書いた通り、Webはハイパーメディアという仕組みで、ハイパーリンク(リンク)によってリソースが結びついて構成されています。

しかし、たまにあると思うのですが、リンクを押してもリンク先のリソースがなくなっている、
いわゆる「リンク切れ」が発生している時ってありますよね。
「なんだもうリンク先のページないじゃん。。残念。。」と思うわけですが、それが当たり前のように発生していたらどうでしょうか。
ハイパーメディアが成り立たなくなり、Webが便利なものではなくなってしまいますよね。

Webができた当初はリンク切れが頻発していたそうですが、Webを発明したティム・バーナーズ=リー氏はこの事態を深刻にとらえ、「Cool URIs don't change(クールなURIは変わらない)」というWebページを公開し、URIが変わらないことが重要であると主張しました。
https://www.w3.org/Provider/Style/URI

変わらないURIの設計

変わらないURIというのは、具体的にどう設計すればよいか。
具体的には、以下を守ることが重要です。

  • プログラミング言語特有の拡張子を利用しない
  • 実装依存のパスを利用しない(cgi-bin、servlet等)
  • プログラミング言語のメソッド名を利用しない
  • セッションIDを含めない
  • 名詞でつける

例えば、プログラミング言語特有の拡張子である.pyや.rbがパスに含まれていると、別の言語に移行する場合にURIが変わってしまいますよね。
また、そのほかに関しても、使用言語や実装が変わった時などにURIも変える必要が出てきてしまうわけです。

「名詞でつける」の部分については、もう少し解説します。

URIは名詞でつける(動詞は使わない)

例えば、以下のようにURIのパスに動詞の/show/が含まれているとします。

http://www.example.com/show/

このページの情報が取得され、ユーザに表示されるだけならいいでしょう。
しかし、このページに例えば何かしらユーザがデータをサーバ側に送る処理を追加しようとしたときに、このページの「show」という文言は違和感が出てきます。

結局のところ、そのページでユーザがどういう動作を行うかはHTTPのメソッド(GET、POSTなど)で決まるわけなので、URIは名詞を使うようにしておけば、このような問題が発生することが防げます。

このセオリーを知らないとうっかり動詞でつけてしまうような気もしますので、これは知ることができて良かったなと思います。

URIをどうしても変えたいときはどうすればいいのか

URIは変わらないことが重要なわけですが、前述のことを気を付けても、変えなければならない状況はあり得ます。
そうなった時には、リダイレクトを使うようにします。
https://e-words.jp/w/HTTPリダイレクト.html

HTTPリダイレクトとは、HTTP通信におけるWebサーバからクライアントへの応答の種類の一つで、要求されたURLが変更された(当該資源が別の場所に移転した)ことを知らせるもの。

つまり、古いURIにアクセスされたときには、新しいURIの方に改めて接続するようにサーバ側を実装するということです。
これにより、リンク切れによってページが参照できないという問題は回避できます。

ここまでのまとめ

  • URIとはURLとURNの総称である
  • URLはリソースの場所を一意に識別するもので、現在はこれでリソースにアクセスするのが一般的
  • URIが変わってしまうと、Webのハイパーメディアという仕組みが成り立たなくなる
  • 変わらないURIを設計することが重要
  • URIが変わってしまう場合にはリダイレクトを利用し、継続してページが参照できるようにする

Discussion