Webを支える技術 第2部 URI

備忘録です。

第4章 URIの仕様

• URI（Uniform Resource Identifier）
  • リソースを統一的に識別するID
  • URLとURNの総称
• URIの例
  • http://yohei:[e-mail]:8000/search?q=test&debug=true#n10
    • URIスキーム: http
    • ユーザー情報: yohei:pass
    • ホスト名: blog.example.jp
    • ポート番号: 8000
    • パス: /search
    • クエリパラメータ: q=test&debug=true
    • URIフラグメント: #n10
• 相対URI
  • 相対URIはURIスキームやホスト名を省いて、パスだけ表現する
• ベースURI
  • 相対URIの起点となるのがベースURI
  • ベースURIの与え方
    • リソースのURIをベースURIにする
      • クライアント側でリソースURIを保存しておかなければならないのがネック
    • HTMLやXMLで明示的にベースURIを指定する
      • , xml:base属性を使う
• %エンコーディング
  • URIでは、ASCII文字（アルファベット、数字、記号）のみ使えるので、日本語などは%エンコーディングする
  • （%エンコーディングでは）大文字小文字は区別しない（大文字推奨）
  • URIに%を使いたい時は、%25などとする
  • サーバー提供のURIなら問題ないが、クライアント側で生成する場合はどの文字エンコーディングを使うか問題になる
    • 一般的には元のWebページのエンコーディングに準じるとよい
    • UTF-8が無難
• URIの長さ
  • 2038バイトまで

第5章 URIの設計

• 変わらない（変わりにくい）URIの設計を目指す
  • 言語依存の拡張子やパスを含めない
    • http://example.jp/cgi-bin/login.pl
      • cgi-binは実装依存
      • 拡張子を入れない
    • http://example.jp/servlet/LoginServlet
      • 特定のサーブレットコンテナを想定している
      • LoginServletの大文字は実装言語依存
  • メソッド名やセッションIDを含めない
    • http://example.jp/Login.do?action=showPage
      • メソッド名を入れない
    • http://example.jp/home.jsp?jsessionid=12345678
      • セッションIDの埋め込み
  • URIはリソースを表現する名詞にする
    • http://example.jp/sample/people/show/123
      • リソースに対するアクションは、URIでなくHTTPメソッドで決定すべき
• loginページの設計例
  • http://example.jp/login
    • ログインフォームリソースのURIを表すのに相応しい名詞は何か
    • loginformやloginpageは冗長なのでloginとする
    • サイトの共通ログインページなのでパスも必要なさそう
• URIのユーザビリティ
  • 端的な名前にする
  • 一般の人でも使いやすい名前にする
• URIを変更したい時
  • 前提として、安易に変更してはならないことに注意
  • 変更する際はできる限りリダイレクトするようにする
• コンテントネゴシエーション
  • クライアントの言語設定に応じて、返すリソースの言語（英語・日本語）を切り替えることができる
  • このように1つのリソースが複数の表現を持つ時、リソースの表現に.ja, .enのような拡張子を使うのは有効
  • 他にも.html, .txt, .jsonなども考えられる
• マトリックスURI
  • ；や,で複数パラメータの組み合わせで表現するリソースに使える
    • http://example.jp/map/lat=35.705471;lng=139.751898
  • ,はパラメータの順序が意味を持つ場合に使う
• URIの不透明性
  • URIをクライアント側で組み立てたり、拡張子からリソースの内容を推測したりできないこと
  • クライアントを作る際は上記の原則を意識しなくてはならない