URIの設計 (Webを支える技術:5章)
【目次】
5.1:クールURI
5.2:URIを変えないようにするための設計指針
5.3:シンプルなURIは、URI自身を変えにくくするだけでなく、ユーザーの使いやすさも良くする
5.4:どうしてもURIを変更したい時は、リダイレクト(転送)する
5.5:設計のテクニック
5.6:URIはクライアントにとって不透明
5.7:URIが重要な理由
【5.1】クールURI
1990年代後半までは、URIが変更になることは日常茶飯事だった
ブックマークに登録してあったお気に入りのWebサイトがある日突然見えなくなる、苦労して作成したリンク集が1年後には半分以上リンク切れ、検索エンジンの検索結果に出てくるページが見つからない
これはWebの根幹を揺るがす問題!!Webはそれぞれのリソースにほかのリソースへのリンクが埋め込まれたハイパーメディアシステム。リンクが切れてしまう=ハイパーメディアシステムが機能しないことになる😱
1998年「Cool URIs don't change」(クールなURIは変わらない)」
「URIは変わらないべきである。変わらないURIこそが最上のURIである」
【5.2】URIを変えないようにするための設計指針
✡指針:実装依存を排除しシンプルにすれば、変更しにくくなる
①URIにプログラミング言語依存の拡張子を利用しない(.pl、.rb、.do、.jspなど)
②URIに実装依存のパス名を利用しない(cgibin、servletなど)
③URIにプログラミング言語のメソッド名を利用しない
④URIにセッションIDを含めない
⑤URIはそのリソースを表現する名詞である
✡指針についてメモ
メソッド名 = プログラミング言語のメソッドのこと。(例)RubyのArrayクラスのsizeメソッド
Ruby on Rails2.0以降では、次のようにメソッド名をURIに含めなくなりました。
railsってそんなことまでやってくれるんだ!触ったことがないのでよく知らないがすごい。。
CGIは廃れていた🤯
Web技術の基本で学んだCGIが、この本では廃れた技術と書かれていた。2010年に発売した本なので2020年現在だとさらに廃れていそう。
リクエストのたびにプロセスを起動するCGI方式は性能面で難点があったため、そのほかの手法に取って代わられました
【5.3】シンプルなURIは、URI自身を変えにくくするだけでなく、ユーザーの使いやすさも良くする
ユーザビリティ=使いやすさ・使い勝手
シンプルだとその分文字数が少ない。=ユーザーが覚えやすい
上記の①~⑤に当てはまらないURIはユーザーには馴染みがない → シンプルだと覚えやすい
→文字数は少なく&シンプルにしよう!
【5.4】どうしてもURIを変更したい時は、リダイレクト(転送)する
現在運用しているシステム(の部分)のURIは簡単に変えてはいけない
しかし、ハードウェアの老朽化、システム全体の機能変更・追加などでシステムを入れ替えなければならないことはよくある
どうしてもURIを変更したいときは、できる限りリダイレクトする
リダイレクトとは
古いURLを新しいURLにリダイレクトさせる仕組み
301は、応答メッセージの中に書いてあるステータス番号
https://gyazo.com/54b161202ddc40a5a63fba66da3a5386
https://gyazo.com/4bab0f44ea1d63b33090443c793e7de2
リダイレクトする仕組みはHTTPサーバーが用意している
→HTTPサーバーとは?:Webサーバーの別名
【5.5】拡張子には良い側面もあるよ
✧ 拡張子で表現を指定する
実装に依存した拡張子はだめという話をしたが、依存しない拡張子は良い面もある。
例えば、日本だけでなくグローバルに活躍する企業のWebページが、日本語と英語で書かれているとする
=このWebページのリソース(Web上に存在する、名前をもったありとあらゆる情報/必ず一意)は1つで、その表現が英語であったり日本語であったりと複数の表現を持つ、と捉えることができる
HTTPのコンテントネゴシエーションという機能を使って、日本語版のOSを使っているユーザには日本語を、英語版のOSを使っているユーザには英語を返せる
リクエスト送るときにHTTPメッセージのヘッダのAccept-Languageは、ブラウザが受信可能な言語をサーバに伝えている。0.7とか0.3はは優先度を表す。ここにjaしか書いてないと日本語しか受け取らない。
コンテントネゴシエーションとは?
HTTP においてコンテントネゴシエーションcontent negotiationは、同じ URL におけるさまざまな表現のリソースを提供するために使用する仕組みであり、ユーザーエージェントはどのリソースがユーザーにもっとも適しているか (例えば文書の言語、画像の形式、コンテンツのエンコード方式) を指定できます。
✧ マトリクスURI
;で区切ってるURI
階層で管理できない情報を表現したいときに使う。
例えば、グーグル・マップの位置情報
緯度と経度のほかにも表示スケール(縮小・拡大)や地図か航空写真かのフラグなど、複数のパラメータが必要になります。しかもこれらのパラメータはそれぞれ独立した軸を持つため、個々のリソースを階層構造で表現できません。
【5.6】URIはクライアントにとって不透明
シンプルなURIは可読性が高いため、ユーザーがURIの構造を推測しやすくなる。
たしかに、無意識に「この情報にいくには上の階層のここにに行ったら取得できそう」とかやったりする。
しかしあくまで、クライアントにとってシンプルだと使いやすいというだけで、URIをクライアンント側で作ったり、拡張子から、リソースの内容を予測することはできない。 = 不透明
なので設計するときは不透明であることを意識するように!
【5.7】URIが重要な理由
URIはリソースの名前である
URIは寿命が長い
URIはブラウザがアドレス欄に表示する