開発初心者の開発日記~16日目~

内容

  • AtCoderでのアウトプット
    • 50分程度
    • 合計で3問解いた、テンプレートも作成した
    • 参考1参考2
  • Webを支える技術でのインプット
    • 110分程度
    • 5.2(54ページ)から6.6(79ページ)まで

Webを支える技術のメモ

第5章:URIの設計

5.2 URIを変わりにくくするには

  • 前提:Webサービスが終了する場合やドメインが変わる場合は難しいが、その他の場合では変わらないような工夫を考える
  • プログラミング言語に依存した拡張子やパスを含めない
    • e.g. 1) http://example.jp/cgi-bin/login.pl
      • cgi-bin.plは実装に依存するが、このようなURIは21世紀には見られなくなった。
      • 理由1:CGI方式が廃れた
      • 理由2:CGI方式の時代にはPerlで書かれていたが、現代では他にもたくさんの選択肢がある
    • e.g. 2) http://example.jp/servlet/LoginServlet
      • 問題点:servletJavaに特有のパス
      • 他言語での実装の際にはこのURIを使えなくなる
  • メソッドやセッションIDを含めない
    • e.g. 1) http://example.jp/Login.do?action=showPage
      • JavaのWebアプリケーションのフレームワークであるStructsを採用した場合のURI
      • 問題点1:Structs特有の拡張子.doが含まれる
      • 問題点2:メソッド名であるshowPageが含まれるので、システムリファクタリングでメソッド名を変更すると、URIも変更される
    • e.g. 2)http://example.jp/home.jsp?sessionid=01234
      • JavaでセッションIDをURLに埋め込むことができる
      • 問題点:ログインのたびにセッションIDが変わり、URIも変わる
  • URIはリソースを表現する名詞にする
    • e.g. 1) http://example.jp/sample/people/show/123
      • 初期のRailsURI
        • 現在:http://example.jp/sample/people/show/123
      • 問題点:showが動詞であること
    • URIの指すリソース(名詞)に対してHTTPメソッドが何らかの操作(動詞)を行う
  • URIの設計方針

5.3 URIユーザビリティ

  • ユーザービリティに寄与するのは?
    • URIのシンプルさ
    • 利点1:文字数が少なくなる
    • 利点2:馴染みのない単語が含まれない
    • 覚えやすく一般人が使いやすいかを意識する

5.4 URIを変更したい時

  • URIを変更しない
    • 運用しているシステムのURIを安易に変更しない
    • 変わらないURIこそクールなURI
  • URIを変更したい場合
    • ハードウェアの老朽化やシステム全体の機能変更の時
    • 古いURIから新しいURIへとリダイレクトする
      • リダイレクトについては後々出てくる

5.5 URI設計のテクニック

  • 拡張子で表現を指定する
    • 実装に依存しない拡張子を用いると良い場面もある
      • コンテントネゴシエーション
        • e.g.) 記事などで複数言語に対応する場合
          • HTTPの機能であるコンテントネゴシエーションにより、日本語版のOSを使用する場合は日本語、英語版のOSを使用する場合は英語、で返すことができる
        • 詳しくは後々出てくる
  • 言語を指定する拡張子
    • コンテントネゴシエーションの場合、ブラウザの設定を変えないと他言語で読むことができない
    • リソースの言語を明示的に示すには下記のようにするとよい
      • 日本語版:http://example.jp/2010/05/01/press.ja
      • 英語版:http://example.jp/2010/05/01/press.en
    • 1つのリソースが複数の表現を持つとき、その表現を示すURIごとに拡張子を変えるのは悪くない
    • 言語以外にフォーマットも含まれる
      • .html.txt.json、など
  • マトリクスURI
    • URIはスラッシュにより階層を表現できる
      • e.g.) http://example.jp/diary/2010/05/01
        • 日付は年→月→日という階層構造を持つため、適している
    • 全ての構造が階層により保持できるとは限らない
      • e.g.) 地図
        • 多次元の情報:緯度、経度、表示スケール、地図or航空写真、など
        • パラメータごとが独立なので階層構造では表せない
    • マトリクスURI
      • 複数のパラメータの組み合わせで表現する場合に利用するURI
      • /の代わりに複数のパラメータを;で区切ってリソースを表現する
      • e.g.)http://example.jp/map/lat=35.705471;lng=139.751898
        • 緯度と経度をパラメータとして含むURI
      • 現在は…?
        • ;:パラメータの順序が意味を持たない場合
          • e.g.)http://example.jp/map/lat=35.705471;lng=139.751898
        • ,:パラメータの順序が意味を持つ場合
          • e.g.)http://example.jp/map/35.705471,139.751898

5.6 URIの不透明性

  • クライアント側での重要なURIの性質
    • http://example.jp/2010/05/01/press.jahttp://example.jp/2010/05/01/press.enから他の言語についてもhttp://example.jp/2010/05/01/press.frのような予測ができる
    • しかし、必ずこのようなリソースが存在するとは限らない
    • また、存在しないリソースをクライアント側で作成するのも御法度
    • あくまでも、Webにおける操作の基本はリンクを辿ること
    • URIのクライアントにおける不透明性
      • 上記のような、拡張子からのリソースの推測やURIのクライアント側での構築ができない性質のことを呼ぶ
      • クライアントアプリケーションの実装の際には意識するべき性質

5.7 URIを強く意識する

  • URIは軽視されがちだが、重要
    • URIはリソースの名前
    • URIは寿命が長い
    • URIはブラウザのアドレス欄に表示される

第6章:HTTPの基本

6.1 HTTPの重要性

6.2 TCP/IPとは?

  • TCP/IPとは?
    • インターネットの基盤を形成するネットワークプロトコル
    • 次以降ではネットワークにおけるプロトコルについて触れる
  • 階層型プロトコル
    • インターネットのネットワークプロトコルは階層構造
    • 層ごとに抽象化して実装することで、下位層によらない実装が可能になる
  • ネットワークインターフェース層
  • インターネット層
    • ネットワークインターフェース層の上にある層
    • TCP/IPにおけるIP
      • データの基本的な通信単位をパケットと呼ぶ
      • 指定されたIPアドレスを送り先としてパケット単位でのデータのやり取りを行う
      • IPでは、ネットワークインターフェースでデータを送り出すことのみを保証している
      • 送り出したデータが多数のルーターを経由して送り先に届くことは保証していない
  • トランスポート層
    • IPでは保証されないデータの転送を保証する層
    • TCP/IPにおけるTCP
    • 接続先の相手に対してコネクションを張る
    • コネクションによりデータの抜け漏れをチェックし、到達を保証する
    • 転送データがどのアプリケーションに渡るかを保証するのがポート番号
      • 1~65535
      • HTTPはデフォルトで80番
  • アプリケーション層
    • トランスポート層の上にある層で具体的なインターネットアプリケーション(メールなど)やHTTPを実現する
    • TCPの場合はソケット呼ばれるライブラリを用いる
      • ソケットとは、ネットワーク上でのデータのやり取りを抽象化したAPIのこと
      • 接続、送受信、切断、などの機能を持つ
      • HTTPサーバやブラウザはソケットを用いて実装する
      • 実際には、それぞれの言語でHTTPの実装はされているので、独自に実装することはない

6.3 HTTPのバージョン

  • HTTP0.9:HTTPの誕生
    • Berners-LeeがWebを発明したときに使っていたプロトコルの俗称
    • HTTPメソッドはGETのみでヘッダも存在しない
  • HTTP1.0:HTTPの標準化
    • 前述のブラウザ戦争が激しかった時期に仕様を策定したため、標準化には至らず
    • ヘッダの導入、GET以外のメソッドの追加、など
  • HTTP 1.1:HTTPの完成
    • 最初のバージョンは1997年に策定
    • 1999年に改定したバージョンが現在のバージョン
    • チャンク転送、コンテントネゴシエーション、など
  • その後のHTTP
    • HTTPの拡張仕様などはあるが、HTTP1.1を有効に利用するのが現代的な開発スタイル
    • 2008年ごろからHTTP1.1の仕様の完成度をさらに上げる活動も

6.4 クライアントとサーバ

  • HTTPの仕組みの基本(クライアント/サーバ)
    • クライアント(ブラウザ)が情報を提供するWebサーバに接続し、各種のリクエストを出してレスポンスを受け取る

6. 5 リクエストとレスポンス

  • HTTPの特徴
    • リクエスト/レスポンス型のプロトコル
      • クライアントが出したリクエストをサーバで処理してレスポンスを返す
    • 同期型のプロトコル
      • リクエストを出したクライアントはサーバからのレスポンスが変えるまで待機する
  • クライアントで行われること
    • リクエストを送信しレスポンスを受信するまでに行うことは以下
    • (1) リクエストメッセージの構築と送信
    • (2)レスポンスが帰るまで待機
    • (3)レスポンスメッセージの受信と解析
      • 解析の際に画像へのリンクなどが含まれる場合は再度リクエストが必要
      • 正しくHTMLなどをレンダリングするためにリクエストを行う
    • (4)クライアントの目的達成するために必要な処理
  • サーバで行われること
    • クライアントからのリクエストを受けたサーバが行うことは以下
    • (1)リクエストが来るまで待機
    • (2)リクエストメッセージの受信と解析
    • (3)適切なアプリケーションプログラムへの処理の委譲
    • (4)アプリケーションプログラムから結果を取得
      • アプリケーションプログラムではデータベースから取得をしたりリンクを生成したりといった処理が走る
    • (5)レスポンスメッセージの構築と送信

6.6 HTTPメッセージ

  • HTTPメッセージとは?
    • リクエストメッセージとレスポンスメッセージをまとめたもののこと
  • リクエストメッセージ
      • GET /test HTTP/1.1
      • Host: example.jp
    • リクエストライン
      • リクエストメッセージの一行目のこと
      • メソッド(GET)、リクエスURI/test)、プロトコルバージョン(HTTP/1.1)、から成る
      • メソッド
        • URIで識別するサーバ上のリソースに対しての処理
        • GETの場合は取得の処理
      • 複雑なURIの場合のリクエストメッセージ
        • GET /search?q=test&debug=true HTTP/1.1
        • Host: example.jp:8000
      • リクエスURI
        • URIフラグメントを除いたパス以降の文字列
        • URIフラグメントはクライアント側で処理するのでリクエストメッセージに含めない
        • パス以降の文字列ではなく絶対URIを用いても良い
          • GET http://example.jp/test HTTP/1.1
          • Host: example.jp
    • ヘッダ
      • リクエストメッセージの二行目以降
      • メッセージのメタデータ(高次のデータ)を表す
      • 「名前: 値」という構成をしている
      • HOSTヘッダは必須で、ポート番号はHostヘッダで指定する
    • ボディ
      • ヘッダの後に続く部分
      • そのメッセージを表す本質的な情報
      • e.g.) リソースを新しく作成する場合(ブログの記事など?)
  • レスポンスメッセージ
    • リクエストメッセージに対して下記のようなレスポンスメッセージを返す
      • HTTP/1.1 200 OK
      • Content-Type: application/xhtml+xml; charset=utf-8
      • <html xmlns="http://www.w3.org/1999/xhtml">
      • ...
      • </html>
    • ステータスライン
    • ヘッダ
      • レスポンスメッセージの二行目以降
      • リクエストメッセージのヘッダと同様の働きをする
      • この例では、Content-TypeヘッダでHTMLのMIMEメディア対応とエンコーディング方式を指定する
    • ボディ
      • ヘッダの後に続く部分
      • ヘッダとの間は空行で区切られ、この例ではHTMLが含まれる
  • HTTPメッセージの構成要素
    • スタートライン(リクエストラインorステータスライン)
    • ヘッダ
    • 空行
    • ボディ