webを支える技術 第3章 REST webのアーキテクチャスタイル　

第3章の読書メモ

3.1 アーキテクチャスタイルの重要性

余談

3.2 アーキテクチャスタイルとしてのREST

抽象化レベル Webでの例
アーキテクチャスタイル REST
アーキテクチャ ブラウザ、サーバ、プロキシ、HTTP, URI, HTML
実装 Apache, Firefox, InternetExploer

余談

  • ネットワークシステムのアーキテクチャスタイルとして最も有名なのは、クライアント/サーバである。

3.3 リソース

  • RESTにおける重要な概念の一つにリソースがある
  • リソースは一言で言うと、「Web上に存在する、名前を持ったありとあらゆる情報」
    • 具体例
  • リソースの名前は、あるリソースを他のリソースと区別して指し示すもの。（他のリソースと区別できなければ意味をなさない）
  • リソースの名前とは、URI（Universal Resource Identifier)
    • 具体例
      • htttp://weather.yahoo.co.jp/weather/jp/13/4410.html
  • URIを用いることで、プログラムはリソースが表現する情報にアクセスできる
  • URIが備える、リソースを簡単に指し示せる性質のことを「アドレス可能性」と呼ぶ。
  • 1つのリソースは複数のURIを持てる（アクセスしやすくなるが、反面どれが正式なURIなのかがわかりにくいと言う欠点も）

余談

  • 昔は、メールでファイルを共有する際、取得方法を詳しく自然言語で説明する必要があった。 （例：FTPサーバーで匿名ユーザーでログインしてください。ディレクトリは/public/dataで、ファイル名はsample_file.gzです。）

3.4 スタイルを組み合わせてRESTを構成する

クライアント/サーバ
  • WebはHttpと言うプロトコルでクライアントとサーバが通信するクライアント/サーバのアーキテクチャスタイルを採用している
    • クライアントはサーバにリクエストを送り、サーバはそれに対してレスポンスを返す。
    • クライアント/ サーバの利点は単一のコンピュータ上で全てを処理するのではなく、クライアントとサーバに分離して処理ができること。
      • これによってクライアントをマルチプラットフォームにできる。
      • UIはクライアントが担当し、サーバはデータストレージとしての機能だけを提供すれば良い。
ステートレスサーバ
  • ステートレストは、クライアントのアプリケーション状態をサーバで管理しないことを意味する。
    • 利点は、サーバー側の実装を簡略化できる
  • 現実にはステートレスでないwebサービスやWeb APIが多々ある。
    • HTTPをステートフルにする代表格はCookieを使ったセッション管理。
キャッシュ
  • キャッシュとは、リソースの鮮度に基づいて、一度取得したリソースをクライアント側で使い回す方式。
    • 利点はサーバとクライアントの間の通信を減らすことでネットワーク帯域の利用や処理時間を縮小し、より効率的に処理できること。
    • 古いキャッシュを利用してしまい、情報の信頼性が下がる可能性もある。
統一インタフェース
  • 統一インターフェースとはURIで指し示したリソースに対する操作を統一した限定的なインタフェースで行うアーキテクチャスタイルのこと。
  • Http1.1では８個のメソッドに限定されている。（GETやPOSTなど）→制約を加えることで、全体のアーキテクチャがシンプルになる。
  • インタフェースを統一することで、クライアントとサーバーの実装の独立性が向上する。
階層化システム
  • システムをいくつかの階層に分離するアーキテクチャスタイル
  • 統一インターフェースを利用すると、システム全体が階層化しやすいという利点もある
    • サーバとクライアントの間にロードバランサを設置して負荷分散したり、プロキシを設置してアクセスを制限したりする
コードオンデマンド
  • プログラムコードをサーバからダウンロードし、クライアント側でそれを実行するアーキテクチャスタイル。
  • 利点は、クライアントを後から拡張できること
  • 欠点はネットワーク通信におけるプロトコルの可視性が低下すること。
  • RESTの提案者のRoy Fieldingの博士論文では、オプション扱いである。
REST = ULCODC$SS
  • 今まで説明した全て追加した複合アーキテクチャスタイル「統一・階層化・コードオンデマンド・クライアント・キャッシュ・ステートレスサーバ」(Uniform Layered Code on Demand Client Cache Stateless Server, ULCODC$SS)をRESTと名付けた。
  • つまりRESTとは
    • クライアント/サーバ：ユーザーインタフェースと処理を分離する
    • ステートレスサーバ：サーバ側でアプリケーション状態を持たない
    • キャッシュ：クライアントとサーバの通信回数と量を減らす
    • 統一インタフェース：システムを階層に分離する
    • 階層化システム：システムを階層に分離する
    • コードオンデマンド：プログラムをクライアントにダウンロードして実行する
  • 実際に設計するときは、いくつかの項目を除外しても良い。理想を念頭に置きながら、実際に動作して価値を提供できるシステムを作ることが重要

余談

  • 無理矢理RESTを採用する必要はない。例えば、P2Pは代表的なREST以外のアーキテクチャスタイル

3.5 RESTの二つの側面

RESTとハイパーメディア
  • Webを使うときの作業の最小単位は、「Web上のリソース同士が持つリンクを辿る」こと。
  • これらの作業をいくつか経ることで、全体として一つのアプリケーションを実現する特徴をRESTでは、「アプリケーション状態エンジンとしてのハイパーメディア」と呼ぶ。アプリケーション状態とは、利用者が持つ状態のこと。
  • ハイパーメディアを用いたアプリケーションには、リソースのURIさえわかれば、あるアプリケーションが提供しているリソースを他のアプリケーションでも簡単に再利用できるという利点がある。
    • 例えば、ソーシャルブックマークの場合、ニュースサイトや開発者用ドキュメントといった別目的のアプリケーションのリソースをブックマークで再利用できる
  • リソースをリンクで接続することで一つのアプリケーションを構成するという考え方はRESTの基幹をなす思想で、これを「接続性」と言う。
    RESTと分散システム
  • RPCなどの分散オブジェクトでは、関数やメソッド単位でサーバ側の処理を呼び出す。ネットワーク越しの関数呼び出しは同一のプロセス内の関数呼び出しとは比べ物にならないオーバーヘッドがあるので、呼び出し回数が多いとシステム全体の性能劣化を引き起こす。
  • では、インターフェースの粒度を大きくして呼び出し回数を減らすことで回避できると言われているが、実際はうまくいかない
    • RPCなどの分散オブジェクトは、サーバごとに別のインタフェースをもち、個々のインターフェースを持ち、ここのインタフェースはプログラムライブラリのインタフェースをベースに開発することが多いから。
  • RESTはRPCの関数でやり取りするデータよりも粒度が大きく、リンクを辿ってアプリケーション状態を背にする方が全体として性能劣化が抑えられる。（RPCの理解が乏しいので、実感値がない）
  • バージョンアップなどにようる互換性の問題は発生しない。統一インタフェースが固定されているから。リソースに適用できるHTTPメソッドは常に固定であり、HTTPを実装したクライアントであれば同じように接続でkリウ。HTTPのマイナーバージョンアップはインタフェースの介護管制を保障する。

    3.6 RESTの意義

  • RESTはWeb全体のアーキテクチャスタイル。
  • 個別のWebサービスやWeb APIがRestfulになると、Webは全体としてより良くなる。

メモ） * Cookieとセッションあたりは別途復習する機会を設ける * プロキシとロードバランサも別途復習する機会を設ける