#おさらい
Webで使われている技術について調べたいと思い、勉強したことをまとめました。
前回は１、２部のことをまとめたため３、４部についてまとめます。（前回分は下記リンクを参照）
#調査内容のサマリー
書籍まとめ①と同様。（上記のリンク参照）
#調査方法
下記の書籍を用いて調査しました。
Webを支える技術 -HTTP、URI、HTML、そしてREST
※わからない単語については随時調べました。
#調査内容
##第３部 HTTP
###第３部を読む前の知識量（大きな独り言）
HTTP言うたらプロトコルやなーてくらいしか知らん。。。
HTTPメソッドはGET、POST。。。あと何があったっけ💦
HTTPの重要性
HTTPはRFC2616で規定されたプロトコルです。
（※書籍では1.1が最新と言っていますが現在のバージョンは3が最新のようです。）
HTTPは、RESTの重要な特徴である統一インタフェース、ステートレスサーバ、
キャッシュなどを実現しているWebの基盤となるプロトコルです。
TCP/IPとは何か
HTTPはTCP/IPをベースにしています。
TCP(Transmission Control Protocol)とIP（Internet Protocol）は
インターネットの基盤を構成する重要なネットワークプロトコルです。
####階層型プロトコル
インターネットのプロトコルは階層型になっています。
| 項番 | 層の名称 | 該当するプロトコル |
|---|---|---|
| 1 | アプリケーション層 | HTTP、NTP、SSH、SMTP、DNS |
| 2 | トランスポート層 | UDP、TCP |
| 3 | インターネット層 | IP |
| 4 | ネットワークインターフェース層 | イーサネット |
HTTPメッセージ
リクエストメッセージとレスポンスメッセージをまとめて「HTTPメッセージ」と言います。
####リクエストメッセージ
「http://example.jp/test」に対する必要最小限のリクエストは下記のようなメッセージになります。
GET /test HTTP/1.1
Host: example.jp
リクエストメッセージの１行目は「リクエストライン」（Request-Line）と呼びます。
メソッド（GET等）、リクエストURI（/test）、プロトコルバージョン（HTTP/1.1）で構成されています。
リクエストメッセージの２行目以降はヘッダが続きます。
各ヘッダは「名前:値」という構成をしています。
上記の例だと「Host」に値「example.jp」が結びつきます。
ボディにはそのメッセージが表す本質的な情報が入ります。
####レスポンスメッセージ
リクエストが成功するとレスポンスが返ってきます。
仮に「http://example.jp/test」のリクエストが成功した場合はサーバはクライアントに
下記のようなメッセージを返します。
HTTP/1.1 200 OK
Content-Type: application/xhtml+xml; charset=utf-8
<html xmlns="http://www.w3.org/1999/xhtml">
...
</html>
レスポンスメッセージの１行目は「ステータスライン」（Status Line）と呼びます。
プロトコルバージョン（HTTP/1.1）、ステータスコード（200）、テキストフレーズ（OK）という構成で成り立つ。
レスポンスメッセージの２行目以降はリクエストメッセージと同様にヘッダです。
レスポンスメッセージにはボディも含まれています。
HTTPのステートレス性
※下記は書籍より抜粋
ステートレスとは「サーバがクライアントのアプリケーション状態を保持しない」制約のことです。
アプリケーション状態とはなんぞやと言うと。。。
※下記は書籍より抜粋
アプリケーション状態は別名「セッション状態」（Session State）とも言う。ログインしてからログアウトするまでの一連の操作をまとめて「セッション」という。この一連の操作の間の状態はアプリケーション状態のことなのでアプリケーション状態とセッション状態は同じ意味となる。
簡単に言うと状態を保持しないのがステートレスと言うこと！！！
逆に「サーバがクライアントのアプリケーション状態を保持する」のがステートフルとなる。
####ステートフルの欠点
ステートフルはクライアントの数が増えれば増えるほどセッション状態を覚えるのが難しい。
膨大な数のクライアントに対してサーバを一つ一つ接続していくのは現実的でない。
ステートフルなアーキテクチャはクライアントの数が増えた場合にスケールアウトしにくい。
####ステートレスの利点
クライアントがリクエストメッセージに必要な情報を全て含めてサーバへ送信する。
サーバ側がセッション状態を覚える必要が無くなり、サーバ側のシステムも単純となる。
ステートフルの欠点を克服でき、スケールアウトも容易となる。
####ステートレスの欠点
リクエストメッセージに全ての情報を送信するため、パフォーマンスが低下してしまう。
またセッション状態を覚えないため認証などサーバに負荷がかかる処理を繰り返してしまう。
ネットワークトラブルが起きた時にリクエストが処理されたかどうかわからない。
HTTPメソッド
| メソッド | 意味 |
|---|---|
| GET | リソースの取得 |
| POST | 子リソースの作成、リソースへのデータの追加、そのほかの処理 |
| PUT | リソースの更新、リソースの作成 |
| DELETE | リソースの削除 |
| HEAD | リソースのヘッダ（メタデータ）の取得 |
| OPTIONS | リソースがサポートしているメソッドの取得 |
| TRACE | 自分宛にリクエストメッセージを返す（ループバック）試験 |
| CONNECT | プロキシ動作のトンネル接続への変更 |
HTTPメソッドとCRUD
| CRUD名 | 意味 | メソッド |
|---|---|---|
| Create | 作成 | POST/PUT |
| Read | 読み込み | GET |
| Update | 更新 | PUT |
| Delete | 削除 | DELETE |
####POSTとPUTの使い分け
※下記は書籍より抜粋
POSTでリソースを作成する場合、クライアントはリソースのURIを指定できません。URIの決定権はサーバ側にあります。逆にPUTでリソースを作成する場合、リソースのURIはクライアントが決定します。
クライアントがリソースのURIを決定できるということは、サーバの内部実装を
熟知していないといけない。その為、PUTの方がサーバの結合が密になる。
※下記は書籍より抜粋
特別な理由が無い限りはリソースの作成はPOSTで行いURIもサーバ側で決定する、という設計が望ましいでしょう。
べき等性と安全性
HTTPの仕様にはプロトコルのステートレス性を保ちながら、通信エラー発生時にも対応するために
ある性質があると言われています。
それは、べき等（Idempotence）と安全（Safe）です。
べき等とは（※下記は書籍より抜粋）
「ある操作を何回行っても結果が同じこと」を意味する数学用語
安全とは（※下記は書籍より抜粋）
「操作対象のリソースの状態を変化させないこと」
####HTTPメソッドは下記の表のように分類できます。
| メソッド名 | 性質 |
|---|---|
| GET、HEAD | べき等かつ安全 |
| PUT、DELETE | べき等だが安全でない |
| POST | べき等でも安全でもない |
Webの成功理由はHTTPメソッドにあり
Webが成功したのはHTTPメソッドを限定して固定したことが要因の一つとして挙げられます。
※下記は書籍より抜粋
HTTPでは非常に数少ないメソッドしか定義されていません。しかしこれこそが、RESTの統一インターフェース制約です。
ステータスコードの分類と意味
| ステータスコード | 意味 | 概要 |
|---|---|---|
| 1xx | 処理中 | 処理が継続していることを示す。 |
| 2xx | 成功 | リクエストが成功したことを示す。 |
| 3xx | リダイレクト | 他のリソースへのリダイレクトを示す。 |
| 4xx | クライアントエラー | クライアントエラーを示す。 |
| 5xx | サーバエラー | サーバエラーを示す。 |
数字で分類するのはクライアントとサーバの約束事を最小限に抑えてクライアントとサーバの結びつきを疎結合にするための工夫です。
システムが疎結合になるとコンポーネント間の独立性が高まり、置き換えや拡張が容易になると言われています。
HTTPヘッダ
※下記は書籍より抜粋
ヘッダは、メッセージのボディに対する付加的な情報、いわゆるメタデータを表現します。
リソースへのアクセス権を設定する認証や、クライアントとサーバの通信回数と量を減らすキャッシュなどのHTTPの機能はヘッダで実現します。
ヘッダは、メソッドやステータスコードと並んでHTTPの重要な構成要素です。
認証
HTTP認証方式には「Basic認証」と「Digest認証」があります。
####Basic認証
ユーザ名とパスワードによる認証。
Authorizationヘッダにユーザ名とパスワードを入れてリクエスト毎に送信する。
DELETE /test HTTP/1.1
Host: example.jp
Authorization: Basic dxNlcjpwYWNzd29yZA==
Basic認証を使う場合にセキュリティの面で配慮が必要。
（ユーザ名やパスワードが平文でネットワーク上に流れるため。）
SSL(Secure Socket Layer)やTLS(Transport Layer Security)を使って
HTTPS(HTTP over Secure Socket Layer)通信し通信経路上で暗号化するか検討が必要。
####Digest認証
Basic認証よりもセキュアな認証方式。
※下記は書籍より抜粋
Digest認証のダイジェストとはメッセージダイジェストの略で、あるメッセージに対してハッシュ関数を適用した結果のハッシュ値のことを言う。
####Digest認証の利点と欠点
#####利点
パスワードを盗まれる可能性がない。サーバ上にパスワードのハッシュ値を保管しておけばいいため、
パスワードをサーバ上に預けなくてもいい。
#####欠点
サーバからのnonceがなければクライアント側でダイジェストを計算できないため
リクエストのたびに「401 Unathorized」レスポンスを得ないといけない。
OpenIDとOauth
OpenIDは「シンプルなシングルサインオン」を実現する仕様。
OpenIDを使うと利用しているWebサービスのアカウントで自作のWebサービスにログインできる。
※下記は書籍より抜粋
Yahoo!やmixiのような、そのWebサービスのアカウントを他のWebサービスにも提供する側のことをIdentity Provider(IdP)と呼び、IdPのアカウントを利用して独自のWebサービスを提供する側のことをService Provider(SP)と呼ぶ。
OAuthは、Webサービス間でデータをやり取りできるようにするための仕様。
キャッシュ
サーバから取得したリソースをローカルストレージ（ハードディスクなど）に蓄積し、再利用する手法。
##第4部 ハイパーメディアフォーマット
###第4部を読む前の知識量（大きな独り言）
HTMLはわかるけどJSONって何やねん。
（JSONはデータフォーマットやな！てくらいしか知識がない。。。）
HTML
HTMLは、Hypertext Markup Languageの略。
マークアップ言語は、タグで文章の構造を表現するコンピュータ言語。
JSON
JSON(JavaScript Object Notation)は、RFC4627が規定するデータ記述言語。
JavaScriptの記法でデータを記述できるのが最大の特徴。
Ajax通信のデータフォーマットとして活用されている。
####JSONに組み込みで用意されているデータ型
| 項番 | データ型 |
|---|---|
| 1 | オブジェクト |
| 2 | 配列 |
| 3 | 文字列 |
| 4 | 数値 |
| 5 | ブーリアン |
| 6 | null |
クロスドメイン通信
不特定多数のドメインに属するサーバにアクセスすることを「クロスドメイン通信」という。
#調査結果（考察も含む）
この書籍でWebを成功に導いた技術を網羅できたのは非常に良かったと思います。
歴史も振り返れたし、満足満足〜。
一度で全部理解するのは難しいからなんども読み返す必要があるかな。。。笑