Webを支える技術 第1部 まとめ
Webを支える技術の第1部をまとめました
第1章 Webとは何か
一般的なWebサイト
UIとしてのWeb
Webサイトだけではなく、ネットワークや家電の設定においても、ブラウザないしはHTMLで記述されたページで操作
何故こういった使い方がされるか
専用のインターフェースやアプリケーションを作るよりコストがかかりにくい、効率的
ブラウザを搭載しており、ネット環境があれば端末の種類を問わず操作可能
APIとしてのWeb
Webを支える技術
様々な用途で使用されるWeb、それは下記のような技術で支えられている
基本的な技術
ハイパーメディア
- 先頭から順当に情報が遷移していくのではなく、非線形的にリンクを選択して情報を取得する形式
分散システム
- 処理を分散させることで、単一のコンピュータでは困難な機能や性能を実現できるシステム
Webは世界中に配置されたサーバに対し、世界中からのアクセスが行われるため超大規模な分散システムと言える
この分散システムの恩恵でWebは実現している
第2章 Webの歴史
Web以前のインターネット
- 最初は米国防総省のコンピュータネットワークとして構築された
- TCP/IPではなく、UUCPで通信を行っていたためタイムラグが発生した
- UNIXに接続するためのtelnetやファイル交換のためのFTP等が存在
Webの特徴、強みである「ハイパーメディア」について
Web以前に存在していたハイパーメディアの特徴
- Webよりも高機能なモノも多かったが、それゆえ複雑になってしまった
Webの実現しているリンクの特徴
シンプルな単方向リンクによって実現
インターネットを用いてるため、不特定多数の情報とリンクさせ合える
ユーザーにとっても分かりやすい
Webの成功は、実装が簡単なシンプルで必要最低限のリンク機能が存在していたから
分散システム
Webはオープンな環境で、不特定多数のクライアントを相手にするシステム
- クライアントのコンピュータ環境(OS、ブラウザ、機種など)が統一されていなくても同じWebサービスできる。
HTTPプロトコルによって、クライアント-サーバ間の通信インターフェースが統一されているため
Webの標準化
Webの急速な普及に伴って、仕様標準化が求められた。
しかし当初は標準化が間に合わず、Web事業に参入した各社の実装がバラバラになってしまい、相互運用能力に欠ける仕様となってしまった。 また、この頃に存在していたブラウザは、それぞれでHTMLとCSSのレンタリング結果が大きく異なっていたため、開発者はブラウザごとの対応を迫られていた。現在では解消しつつあるものの、未だにIEなどのブラウザ対応が行われているのはこの時代の名残である。
様々なハイパーメディアフォーマットの誕生
Atom Webページで新着情報を取り扱うためのフォーマット
JSON データフォーマットとして、HTMLやAtomは冗長 ↓ 単純で機械や人間にとっても可視性の高いフォーマットとして「JSON」が誕生
WebAPI
分散システム(オブジェクト)の標準化を進めるため、WebAPIを構成する2つ仕様が発生
- SOAP
- REST
- 分散システムにおける考え方
- リクエストは「GET」「POST」などによって行われ、レスポンスについてはフォーマットの指定が無い
- 不特定多数の人が利用する、入出力に対して厳密無くてもよいサービス向け
結果的には、「簡単でシンプル」「政治的理由」によってRESTの方に軍配が上がった。
全てがWebへ
バックエンドのプロトコルは現在に至っても変化はしていないが、UIはWebで統一されつつある。 また、一台のコンピュータで行えない処理も、Webを通じてインターネット上のコンピュータの力を借りて実現できている。 こういったことから、今後もWebの重要性は増すばかりである。
第3章 REST Webのアーキテクチャスタイル
RESTはWebのアーキテクチャスタイルであり、クライアント/サーバのスタイルから派生したWebの設計思想のことである。
また、このRESTの制約に遵守してサービスを作ることがWeb全体で統一した設計をすることができる。
リソース
RESTにおいて「リソース」は重要な概念だ。 Web上のあらゆる情報は、全てリソースとして取扱われる。
例
- 動画
- ニュース
- ページ
また、これらのリソースはWeb上の無数のサーバーに存在しており、プログラムで利用するためには、どのサーバーにあるどのリソースが必要なのか正確に判断するための材料が必要になってくる。
それを解決するために「URI」という重複しない、一意な名前を割り当てられている。
URIは「プロトコル」「サーバー情報」「ディレクトリ構造」「ステータス」といった情報を一文でまとめたもので、プログラムでの処理やアクセスを容易にできる。
RESTに含まれているアーキテクチャ
クライアント/サーバ
Webは、HTTPという通信プロトコルでクライアント-サーバ間の通信を行う「クライアント/サーバ」のアーキテクチャスタイルを採用している。 これは、クライアントから送られたリクエストに対し、サーバがレスポンスを返すという方式であり、クライアントはUI、サーバはデータを担当することで、処理を分散できるメリットがある。
また、クライアントはUIのみを担当すれば良いので、PCだけでなく携帯電話やゲーム機などのプラットフォームからもアクセスすることができる。
ステートレスサーバ
クライアントのアプリケーション状態をサーバ側で管理しないアーキテクチャスタイルであり、サーバ側の実装の簡略化に繋がる。 また、サーバの行う処理を軽減することも出来る。
しかし実際には、Cookieを利用したセッション管理を行うステートフルなサービスも多く存在しており、REST的には間違っていると言える。 ただし、現実的に考えてそれらを全てステートレスに置き換えるといったことは出来ないため、最低限に留めつつ利用することが大切だ。
キャッシュ
一度取得したリソースをクライアント側で保存をしておき、再度必要になったときに使い回す方式。 クライアント-サーバ間での通信量を減らすことや処理時間の短縮に寄与するが、取得した時の情報が古いくなっていた場合、情報の信頼性が下がってしまう。
統一インターフェース(UI)
リソースの操作を制限を設けることで、システムを多種多様のクライアントやサーバに対応させるアーキテクチャスタイル。
階層化システム
システム全体をいくつかの階層に分割するアーキテクチャスタイル。
RESTにおいては、インターフェースをHTTPで統一しているため、途中で階層構造を変更してもクライアント側は大きな影響無く利用することが出来る。
コードオンデマンド
プログラムコードをサーバからダウンロードして、クライアント側で実行処理を行うスタイル。
例
この方式には、クライアントにあらかじめ用意しておいた機能だけでなく、後から機能を追加できることやFlashやJavascriptを利用した派手なサービスも提供することができる。 また、処理はクライアント側で行うため、サーバ側の負担を軽減することが出来る。
しかし、クライアント側でプログラムが実行されるため、サーバ側からプロトコルの可視性が低下してしまうといった欠点も存在する。
※参考
・Webを支える技術 https://www.amazon.co.jp/dp/4774142042/ref=cm_sw_em_r_mt_dp_U_LiIUEbQ3NJSJH
