1分で理解する「Webを支える技術」: URI編
前回
4章: URIの仕様
URIとはリソースを識別する一意(重複がない)のIDのこと。
つまりWeb上に存在する全てのリソースを一意に示ます。
URIの構成
QiitaのタイムラインであるURIを構成するパーツは次のようになる
- URIスキーム
- https
- URIが利用するプロトコルを示すのが一般的。://で区切られる
- ホスト名
- qiita.com
- インターネットの住所的なやつ。被ることはない
- パス
- timeline
- インターネットの部屋的なやつ
%エンコーディング
URI仕様が許可している文字以外をURIに入れるには、%エンコーディングでその文字をエンコードする必要がある。
ひらがなの「あ」を解説する記事をブラウザで閲覧すると、アドレス欄には次のURIが表示されるでしょう。
上記URLをコピペして貼り付けると↓に変換される
https://ja.wikipedia.org/wiki/%E3%81%82
これは「あ」はURI的に許可されていないのでブラウザとサーバの間で転送(変換)されるためである。
5章: URIの設計
よくないURI
http://example.jp/Login.do?action=showPage
.doも問題だが、注目するのはshowPage。
例えばshowPageの命名を変更した時にURIを変えなければいけないので手間がかかる
http://example.jp/home.jsp?jsessionid=12345678
セッションIDはログインの度に変わるため、上記URIにアクセスする度に毎回ログインすることになるかもしれない
http://example.jp/sample/people/show/123
初期のrailsで見られた構成。
パスの部分はsampleアプリケーションのPeopleコントローラのshowメソッド、123はデータベースのIDになる。
このshowが問題。HTTPではリソースに対して特定のHTTPメソッドだけを適用する。
あるリソースを取得するのかor更新するのかの判断はURIで指定するのではなく、URIに適用するHTTPメソッドで決めるべき。
つまりURIとHTTPメソッドはそれぞれ名詞、動詞であるべき。
まとめ
・URI はリソースの名前である
・URI は寿命が長い
・URI はブラウザがアドレス欄に表示する
Discussion