一章 Webってなに

Tweet

Webとは？

たまたま通りかかった人に「ねえ、Webってなに？」といわれると、回答に困るかもしれない。
まずは、「そもそもWebってナニ」という広い入口から考える。

Webの用途

Webは、大きく分けて3つの用途で使われている。

• Webサイト：Yahoo!とかGoogleとか
• ユーザーインターフェイスとしてのWeb：各種デバイス載せてい画面(プリンタとか)
• API：プログラム向けのインターフェイスのこと。

Webを支える技術

Webがいろんなところに使用されているのは、わかった。
では、どんな技術が使用されているのか？
まとめてみた。

Webの歴史

Web以前のインターネット

正直、意味がよくわからなかったなぁ。
だって、生まれたときからWebが当たり前の世代だったし。

黎明

インターネット初期には、Webがなかったみたい。では何ができたのか？
最初は、メールだけだったみたい。しかも、リアルタイム通信の「TCP/IP」に加えて、バケツリレー方式の「UUCP」による転送もあったらしい。
そのせいか、結構遅延することもあったみたい。

少し進化

メール以外にも、ファイル交換のためのFTPや、リモート接続のためのTelnetとか出てきた。

Webの誕生

初期のWebは、学術論文の交換に使用されていた。

1980年代

1980年代までに、「ハイパーメディア構想」と「インターネット」「分散システム」の考え方が広まった。
webはこんな時代に生まれた。
webは最初企業や研究者が使っていたが、コンテンツを公開することで、Webの普及を進めた。

1990年代

1990年代になると、めちゃくちゃ広まった。広まりすぎて、互換性が追い付かなかったこともある。
3WCによって標準化されたが、ブラウザごとの対応等はこのころからあった。
(お猿も「Chrome」と「edge」でちょっと苦しんだ。)
このころには、Webがなぜ成功したのか？それをアーキテクチャの観点から分析。
アーキテクチャのスタイルの一つとして「REST」を発表した。

2000年代

2000年代になると、「自動化したい」という要求が増える。
そんな中誕生したのがWebAPI。

RESTとは

RESTとは、Webアーキテクチャスタイルのことである。
Webの持つ「クライアント/サーバー」というアーキテクチャスタイルに制約を加えると、RESTになる

ネットワークシステムのアーキテクチャスタイル

有名なのは「クライアント/サーバー」。Webは、「クライアントサーバー」を適用し、改良を加えることで、RESTも適用している。

ここで一回確認

アーキテクチャとか、アーキテクチャスタイルとか、書いてわけわからなくなってきたので、一回まとめる。

Restで大事なこと

リソース

Webにおける、リソースとは「Web上に存在する名前を持った情報」のこと。
リソースの名前はURIで一意の名前を持つ。
URIを用いることで、プログラムはリソースが表現する情報にアクセスできる。

なお、URIが持つリソースを簡単に示せる性質のことを、「アドレス可能性」と呼ぶ。
同じリソースにURIを複数設定することができるが、管理がややこしくなる。

サーバーとのやり取り

リソースは「Web上に存在する情報」である。
サーバーとクライアントがやり取りをするとき、具体的なデータを送信しあう。
この時、やり取りするデータのことを、「リソースの表現」と呼ぶ。

RESTを構成する要素

RESTは、複数のアーキテクチャスタイルを組み合わせた、「複合アーキテクチャスタイル」である。
組み合わせているアーキテクチャは下の通り。

クライアントサーバー

特徴

• クライアントとサーバーに分かれて処理する。
• クライアントは、PCに限らず携帯などでも可能
• 複数のサーバーを組み合わせて冗長化し、可用性を高められる。

ステートレスサーバー

特徴

• クライアントの状態をサーバーで管理しない。
• サーバー側の実装が簡略
• WebAPI等が該当

※Cookieはステートフルにする仕組み。ステートレスの利点がなくなることに注意

キャッシュ

特徴

• リソースの鮮度に基づき、一度取得したリソースを使いまわす。
• クライアントとサーバー間のやり取りを減らせるので、高速対応が可能。
• ただし、リソースが古い可能性があり、信頼性がやや下がる。

統一インタフェース

特徴

• URIで指示したリソースに対する操作を限定的なインタフェースで行う。
• (例)HTTPメソッドはPOST,GET等、8個。拡張できない。
• 限定することで、シンプルになり、独立性が確保できる。

階層化システム

特徴

• サーバとクライアントの間に「プロキシ」や「ロードバランサ」を導入することで、負荷分散(プロキシ)やアクセス制限(ロードバランサ)が可能
• ステートレスサーバーを中継することで、レガシーシステムにアクセスも可能。

コードオンデマンド

特徴

• プログラムコードをサーバーからダウンロードして、クライアント側で実行する(Javascript とか Flshとか)。
• クライアントを後から拡張できる。
• リソースがプログラムなので、プロトコル自体の可視性は下がる。