はじめに
初心者がWEBを支える技術を読むにあたり、単語の意味とそれが何を示してるのかわからないので
読んで進めていても理解しにくい。自分なりに理解し、アウトプットする事で、理解を深めていく。
WEBとは何か？
大きく３種類に分類される。
WEBサイト
一番イメージしやすい。グーグルのページとか。
どうやって表示しているのか、どうやって処理しているのかをイメージしなくても
ユーザーが使えるのがWEBの魅力である。
ユーザインタフェースとしてのWeb
見た目を整えて、ブラウザの設定をしたりする。
昔はハードのリモコンボタンでしていたが、今はブラウザ上で設定するのがほとんど。
端的に言えば、フロントエンドエンジニアが関わる領域。
プログラム用APIとしてのWeb
本書では、ややこしいのでWebAPIと呼ぶ。
端的に言えば、バックエンドエンジニアが関わる領域。
APIはプログラム用のインタフェース。ってイメージ。
データフォーマットにはXML（ExtensibleMarkupLanguage）
JSON（JavaScriptObjectNotation）を使う。
XMLについて詳細 https://www.graffe.jp/blog/2911/
JSONについて詳細 https://www.json.org/json-ja.html
WEBを支える根幹の技術
HTTP（URLとHTMLをやり取りする為する取り決め）
URL（WEB住所）
HTML（WEB文字）
HTMLはXMLを基にした汎用の言語。
ハイパーメディアと分散型システム
WEBを支える技術の根幹にある。
ハイパーメディア
リンクでデーターを結びつける事。
書籍などで目次を確認する以外だと"ドラえもんの生態"のページを探すには先頭から読むしかなかったが
リンクを結びつける事で"ドラえもん"と検索するだけで対象ページが見つかるようになった。
分散システム
一箇所にあるコンピューターで処理するのでなく、世界中に散りばめられたサーバーにアクセルする事で多数のコンピューターで処理ができる。
様々なパソコンが同時にアクセスし処理ができるのは、HTTPのプロトコルが簡単だから。
WEBの歴史
インターネットの始まりなどは割愛。
RPCは分散システムを実現する為に必要な技術（昔は）
ただ、問題があり、大規模分散システムとはならない。
1990年にバーナーズリーガWEBを発明。サーバーとブラウザを公開。
最初流行ったブラウザはモザイク。
RPCと違い、HTTPのプロトコルが簡単だから流行った。誰でもアクセルできるって感じかな。
ロイフィールディングがWEBのアーキテクチャを決定付けた（構造）
このアーキテクチャをRESTと名付けた
ハイパーメディアの複雑化
情報のやり取りがHTMLだけだと対応できなくなって新たな仕組みが生まれた。
microformats
RSS
JSON
今後学習する上で必要なら上記言葉の意味を理解するにとどめる。
文書を読むためのWEBからプログラムを実行するためのWEBへ
アマゾンが2002年に自社で扱う書籍のデーターをWEBを通じてプログラムで取得する技術を開発した。
これにより、WEBを使って処理するのが素晴らしいと世の中が便利さに気づき始める。
RPCの技術を発展させたプロトコルも出てはいたが、複雑さと政治的な理由から現在のWEBの技術にインターネットが飲み込まれ始める。
RESTというアーキテクチャスタイル(第３章始まり)
アーキテクチャスタイルとはRESTその物の事をさす。
実装を一つ抽象度をあげたものをアーキテクチャと呼び更に抽象度をあげたものをアーキテクチャスタイル（REST）と呼ぶ。
RESTを構成する重要な概念を順に紹介する。
リソースとは
RESTの重要な概念の一つ。WEB上に存在するありとあらゆる名前を持った情報の事。
リソースの名前とはURLの事です。
このURLがもつリソースの情報を簡単に指し示す事のできる性質を＜アドレス可能性＞よーするにURLにちゃんとした名前をつけておけば、プログラムを作成しやすくなります。一つの情報は複数のURLを持つ事ができる。サーバーとクライアントの間でやり取りするデーターを＜リソースの表現＞と呼ぶ。
サーバーとクライアント（アーキテクチャスタイルその１）
HTTPプロトコル。プロトコルとは手順や約束事。HTTPプロトコルに準じて、サーバとクライアントがやり取りをする。
この仕組みのメリットはクライアントとサーバを分離し処理ができる。だからクライアントをマルチプラットフォームにできる。よーするにWEBは携帯からPCゲームまでなんでもやり取りができる。しかもUIはクライアント側の仕事のため、サーバーはデーターストレージとしての機能をもつだけで良い。 （ストレージ 記憶装置）
ステートレスサーバー（アーキテクチャスタイルその２）
クライアントのアプリケーションの状態をサーバーで管理しない事。これによりサーバーの実装を簡素化できる。ただ現実にはCookieを使ったセッション管理などあえてステートレスではない処理をしているケースもある。あくまでの必要最低限の実装にする理解で留めておく。
キャッシュ（アーキテクチャスタイルその３）
一度取得したリソースをクライアント側で使い回す事。
メリットはサーバーの通信を減らすことで負担減となる。
統一のインターフェイス（アーキテクチャスタイルその４）
限定した８個のメソッドで処理をする。これ以上メソッドを拡張出来ない制限を加えることで、シンプルなアーキテクチャを実現した。この統一インターフェイスがRESTを印象づけるアーキテクチャです。
階層化システム（アーキテクチャスタイルその５）
統一UIを採用していることで階層化システムを採用しやすくなっている。
サーバーの負荷分散のためにプロキシを設置してアクセスを制限したりする。
プロキシとは
直訳は代理。統一したUIのおかげで、クライアントはプロキシに繋がろうが、サーバーに繋がろうが、意識することはない。
サーバーに対しては、クライアントの情報を受け取る。クライアントに対してはサーバーの情報をサーバーの働きをする。
コードオンデマンド（アーキテクチャスタイルその６）
サーバーからプログラムコードをDLしてクライアントで実行するアーキテクチャスタイル。
メリットはクライアントを後からいくらでも拡張できる事。HTTPアプリケーションプロトコルに従って通信している間はリソースは明白なのに対して、DLしクライアントで実行してしまうので、可視性は低下する。
RESTのアーキテクチャスタイルのまとめ
この６つを組み合わせたアーキテクチャスタイルをRESTと呼ぶ。
1クライアント/サーバーをで分けて、ユーザーインターフェイスと処理を分離する事
2ステートレスサーバー（サーバー側でアプリケーションの状態を持たない）
3キャッシュ（サーバーとクライアントの通信を減らす）
4統一インターフェイス
5階層化システム
6コードオンデマンド
アプリケーション状態エンジンとしてのハイパーメディア
WEB上のリソースが持つリンクを辿ってその作業をいくつか実施することで一つのアプリケーションを実現すること
この考え方は接続性とも呼ばれる。
RESTful
RESTの制約に従って、RESTらしい設計をする事
URLの設計と実装について（第４章始まり）
URLは日本語で言い換えると、リソースを統一的に認識するID。つまりURLさえあれば、WEB上にあるリソースを全て指し示す事が出来る。
URLを構成するパーツの例（簡単な構成バージョン）
http://blog.example.jp/entries/1
まずリソースにhttpでアクセスすると宣言。://をつけるのがルール。
ホスト名は必ず被らない名前かIPアドレスを使う。そのホストの中でリソースが被らないように階層パスが続く。
・URIスキーム：http
・ホスト名：blog.example.jp
・パス：/entries/1
URLを構成するパーツの例（複雑バージョン）
http://yohei:pass@blog.example.jp:8000/search?q=test&debug=true#n10
ユーザー名とパスワードは<:>で区切ります。
HTTPのポート番号のデェフォルト値は８０番です。
クエリパラメーターはクライアントから動的にURLを生成します。（いまいちわからん）
URIフラグメントはクエリパラメメーターで指定したURLのさらに細かいリソースを指定するときに使用する。
例えば、それがHTML文だった場合はod属性値がn10である要素となる。
・URIスキーム：http
・ユーザ情報：yohei:pass
・ホスト名：blog.example.jp
・ポート番号：8000・パス：/search
・クエリパラメータ：q=test&debug=true
・URIフラグメント：#n10
相対URIと絶対URI
絶対URIは階層全て記載するイメージ。
http://example.jp/foo/bar
相対URI
URIスキームやホスト名を除く。
/foo/bar
見てわかるように、相対URIだけではクライアントが場所を認識できない。
相対URIでもURIを認識するようにしなければならない。
その為に絶対から相対にURIを変える事を相対URIを解決するという。
相対URIを解決する手段
HTMLの場合、
に情報を加え、明示的にする。％エンコーティング
URIで対応していない文字列を変換し表示すること。
URI長さ制限
IEが２０３８バイトまでしか対応していないので、それ以下の容量とする。
URI実装で気をつける事
相対URIを解決する事。
％エンコーティングの扱いでUTF-8を使用する事。
URIとURLの違い簡単に説明
URIはURLとURNの総称。
URLはドメインを更新しない時やサーバーが何かしらの障害で変更になったときにアクセス出来なくなる仕組み。
その保険的なイメージでURNとはドメイン名とは独立してリソースに恒久的にID（名前）をつける事。
但し、URNは取得ができない。WEBの価値が向上し、URLで十分永続的に接続出来るようになっている。
インターネットのプロトコルは階層型 第６章
4つの層に分かれている。
ネットワークインターフェイス層
物理的なケーブルやアダプタに相当する部分。
インターネット層
この層を担当するのが、IPです。IPではデーターの通信単位をパケットと呼ぶ。
パケットとは指定したIPアドレスをパケット単位で通信している。
送り出したデーターが最終的な送り先まで届くかは保証しない。
トランスポート層
IPが保証しなかったデーターの転送を保証する。TCPが相当する。
保証の仕方は、コネクションを使って漏れをチェックする。どのアプリケーションに渡るのかを決定するのがポート番号。
アプリケーション層
HTTPやメールやDNSを実現する層です。
HTTPのバージョンについて
今は１、１で後継のバージョンも議論されている。
ただ、現在ではRESTアーキテクチャスタイルに価値を見出しており、HTTP１.１を有効に活用できる開発をしていく流れとなっている。
リクエストとレスポンスについて
HTTPはクライアントが出したリクエストをサーバーで処理してレスポンスを返します。
クライアントはレスポンスが返るまで待機します。
クライアントで行われる事
１.リクエストメッセージの構築
２.リクエストのメッセージの送信
３.（レスポンスが返るまで待機）
４.レスポンスメッセージの受信
５.レスポンスメッセージの解析
６.クライアントの目的を達成するために必要な処理
サーバーで行われる事
１.(リクエストの待機)
２.リクエストのメッセージの受信
３.リクエストメッセージの解析
４.適切なアプリケーションプログラムへの処理の委譲
５.アプリケーションプログラムから結果を取得
６.レスポンスメッセージの構築
７.レスポンスメッセージの送信
HTTPメッセージ
リクエストメッセージとレスポンスメッセージをまとめた言い方。
HTTPのメッセージの構造
ステートフルとステートレスについて
RESTの設計の重要なアーキテクチャである。
ステートレスなサーバー設計ですが、意味を完結に表すなら、ステートレスはくどい会話になる。
一見ステートフルがいいように見えるが、無数のクライアントのリクエストを受けるサーバーにおいて、処理しきれない問題が生じる。
ステートレスの欠点
送信するデーター量が多くなる。
リクエストを重複してレスポンスを返す恐れがある。
hoges
