5分で理解する「Webを支える技術」: Web&REST編

# 1章: Webとは何か
### Webの主な用途
- Webサイト
    - GoogleなどのポータルサイトやAmazonなどのショッピングサイト
- システムに人の手が触れる部分(ユーザーインターフェイス)としてのWeb
    - ルータやテレビなどの各種デバイスの設定画面など
- プログラム用のAPIとしてのWeb
  - プログラム用のインターフェイス[^1]。形式はXMLやJSONなどがメジャー


### Webを支える技術

- URI
    - URIを指定すればあらゆるWebサイトが見れる
- HTML
    - URIで指定したサイトの情報を表現する文章フォーマット
- HTTP
    - プロトコル[^2]を使ってHTMLなどを取得したり発注したりする
 
これらに支えられたWebは以下の2つの要素を持っている
- ハイパーメディアシステム
- 分散システム

### ハイパーメディア
画像、音声、映像などさまざまなメディアをハイパーリンク[^3]で結びつけた構成システムのこと。

```mermaid
flowchart LR
a[URI]
b[HTTP]
c[HTML]
a <--> |HTTPはURIで操作対象を指定する|b
b <--> |HTMLはHTTPでやりとりされる|c
c <--> |HTMLのリンクはURIを利用する|a

```

### 分散システム
1つの中央コンピューターが全てを処理するのを集中システムと呼ぶのに対して、分散するのを分散システムという。
分散システムは複数のコンピューターやプログラムをネットワーク上に分散して配置し、1台のコンピューターでは扱いきれない膨大なデータを操作できるメリットがある。




# 2章: Webの誕生
### Web登場まで
インターネットの起源は1969年と言われている。
色々な技術があったがブラウザが登場するまで下記のような問題があった。

- ネットワーク[^4]越しの関数呼び出しは1つのコンピューターで関数を呼び出すのに比べて何倍もの時間がかかる
- 複数の言語が混在する環境ではデータ型の変換時に問題が発生することがあった
- サーバーのインターフェイスを更新した時、古いバージョンのコンピューターが上手く作動しないことがあった
- 分散システムを採用した場合、サーバー上にコンピューターのアプリケーションの状態を保存するが、多数のサーバーで負荷を分散するのが難しい

### Mosaic誕生
1993年ブラウザMosaicが誕生。
それまでのブラウザはブラウザ単体では文字情報だけしか扱えなかったが、Mosaicは本文にインラインで画像を載せることができた。MosaicはIEやchromeの源流になっている

### Webの標準化
Webのメリットは下記の通り

- インターネットを使ってハイパーメディアを不特定多数の情報をリンクさせさせ合うことができ、システムを大規模しやすくした
- OSやハードウェアが統一されてなくても、様々なブラウザやデバイスで1つのWebサービスにアクセスできるようになった

1990年代後半からニュース、娯楽メディア、ショッピングなど様々なジャンルがWebに参入したことでURI、HTTP、HTMLの標準化が求められた。なぜなら現状Webが急速に普及認め、各社の実装がバラバラになってしまったため。

1994年にはW3CというHTML、XML、HTTP、URI、CSSなどの標準化作業が行われた
当時流行していたIEなどのブラウザが独自拡張を繰り返した結果、ブラウザ毎にHTMLとCSSのレンダリング結果が異なる事態が発生した(この数十年間にIE対応が行われた原因である)

### RESTの誕生
Webがなぜこんなに成功したのか？なぜこれほど大規模になったのか？についてソフトウェアアーキテクチャ[^5]の観点で分析し、1つのソフトウェアアーキテクチャにまとめたものをRESTと名づけた。

### JSONの誕生
初期のWebではHTMLが唯一のハイパーメディアフォーマットだった。
しかし、様々な要望が生まれたことで新しい形式のハイパーメディアが生まれた。
[Microformat](https://developer.mozilla.org/ja/docs/Web/HTML/microformats)、[RSS](https://www.soumu.go.jp/menu_kyotsuu/rss_information.html)、Atomの順番で標準化されました。
Atomはマークアップ言語のため表記が長いという欠点があって、もっと単純なフォーマットの方がいいよね！ということでJSONがスタンダードになりました。

### SOAPの存在
端的に言ってしまえばRESTのライバル。
HTTPとは違う方式でプロトコルしよーぜ！というノリで誕生した。
詳細は[こちら](https://e-words.jp/w/SOAP.html)参照。

### SOAP VS REST
SOAPとRESTに関する論争は2000年前後から始まった。
RESTが大流行し始めたのは2002年のAmazon Webサービスが出てきてから。
Amazonは自社で扱う書籍などの商品の情報を下記の2つの形式で実装した
- SOAP形式
- URIをHTTPでGETする方式の2つの形式でプログラムから取得する

後者と便宜的にREST形式と呼んだ。
色々議論バトルはあったもののシンプルで使いやすいという理由でRESTが世間から受け入れられた。

### 全てがWebへ
RESTが普及されるのと並行して、Webはインターネット全体を飲み込み始める。
メールやネットニュースといったバックエンドで動作しているプロトコルに変化はなかったが、ユーザーインタフェースは全てWebで統一され、利用ユーザーはWebだけを意識するようになった。
この背景にはAjaxなどの技術が登場したことによってユーザインターフェイスと使い勝手が物凄くよくなった。
例えば地図ソフトであれば1つのデバイスにインストールしてそのデバイスしか使えなかったが、現在ではサーバー側から地図をダウンロードすればいつでも&どこでも地図が見れるようになったなど

# 3章: REST
### RESTとは？
RESTはネットワークシステムのアーキテクチャスタイルとして有名。
一般にソフトウェアアーキテクチャは複数のコンポーネント(部品)を組み合わせて実現しますが、それがバラバラだと動作しません。
そこで各コンポーネントに制約をかけることで全体として各コンポーネントが協調して動作するようになります。
アーキテクチャスタイルは特定の実装やアーキテクチャを指している訳ではないことに注意。
それぞれ例を挙げると下記の通り

|抽象化レベル  |Webでの例  |
|---|---|
|アーキテクチャスタイル  |REST|
|アーキテクチャ  |ブラウザ、サーバ、HTTP、URI、HTMLなど |
|実装  |IE、Firefoxなど|


### リソース
RESTを知るにはリソースの理解が必要。
Webにおけるリソースの例は下記の通り

- Qiita
- Yahoo知恵袋

などWebに存在する名前を持ったあらゆる情報になる。
Qiitaは技術サイトでありますが、仮に全く違うWebサービスのQiitaが誕生したらどうやって区別するのか？
答えはリソースの名前で管理すること。もっと詳しくいうとURIで識別する。
世界中の無数のリソースはそれぞれURIで一意(重複がない)の名前を持つ。
また、URIを用いることでプログラムはリソースが表現できる情報にアクセスできる
- Qiita
    - https://qiita.com/
- Yahoo!知恵袋
    - https://chiebukuro.yahoo.co.jp/
 
1つのリソースには複数のURIを持つ。
Qiitaで言えば下記の通り

- トップページ
    - https://qiita.com/
- タイムライン
    - https://qiita.com/timeline
- トレンド
    - https://qiita.com/trend

[^1]: 2つの要素の接点や境界面といった意味
[^2]: ネットワークを通じてコンピューター同士がやりとりするための約束事。日本語の朝の挨拶は「おはよう」、英語だと「
Good morning」みたいな感じ
[^3]: 「リンク」の正式名称と認識して頂ければ多分大丈夫です。
[^4]: コンピューター同士でデータ等をやりとりする仕組み。ネットワークがない時はフロッピーディスクとかを人に渡してたらしい
[^5]: システムの組織または構造を示し、それがどのように機能するかを説明するもの