# プロになるためのWeb技術入門（LESSON5まで）
## LESSON4 CGIからWebアプリケーションへ
### 4.1～4.3 宅配ピザ注文サイトを作ろう
このレッスン以降、宅配ピザを注文するサイトの作成を例として扱っている。
サイトはログイン画面からログインし、商品一覧からピザを必要分だけ選択する。確認画面を経て注文完了画面へ推移し、ログアウトしてログイン画面に戻る。
画面はhtmlのみで模造品となる「**モック**」を作成してから行う。
### 4.4 ログイン認証機能の作成
まずはじめに、ログイン認証機能を実装する。
#### ログインコントローラーver.1の処理
1. 入力画面からPOSTで送られたリクエストパラメータを受け取る。
2. 事前に登録してあるデータとリクエストパラメータを照合する。
3. 照合成功→商品一覧画面へリダイレクトする。
4. 照合失敗→ログイン失敗画面へリダイレクトする。
※**リダイレクト**：リクエスト元URLとは異なるURLに誘導すること。ログインリクエストに対するレスポンスには302 FOUNDが返り、これを受けて別URLに再度リクエストを発行する。
#### ver.1の問題点
ログイン画面を経由せず、直接商品一覧画面のURLを入力した場合、アクセスできてしまう。→各画面における**ログイン状態の有無が不明なため。**
### 4.5 ログイン情報を記憶する
#### 4.5.1 ステートレス性に対処する
FTPは**ステートフルプロトコル**である。リクエストと共にFTPサーバが状態を保持するため、途中のリクエストからの割り込みは不可能である。
HTTPは**ステートレスプロトコル**である。1リクエスト・1レスポンスをもってリクエストは完了となり、完了した時点で扱ったデータは破棄される。つまり、**次のリクエスト時に状態が引き継がれない問題点がある。**
#### 4.5.2 クッキーを利用する
**クッキー（Cookie）** は、リクエスト内容に状態を表すデータをつけ、その後のやりとりで参照するものである。HTTPを拡張した技術のため特別なプラグインは必要ない。
具体的には、リクエストヘッダに必要な情報をクッキーとして「名前＝値」の形で記述する。この値をチェックすれば、URLの直接入力問題でログイン状況が分かり、不正な入力の排除が可能となる。
#### ログインコントローラーver.2と、その問題点
ver.2ではクッキーをやり取りし、ログイン状態を扱っている。
このver.2の問題点としては、クッキーのやり取りについてである。クッキーはヘッダに記述されるため、ツールで状態を簡単に覗けてしまう。
**→クッキーを利用した機密情報のやり取りは危険！**
### 4.6 安全に状態を保存する：セッション
セッションとは、一連の処理の流れを指す。セッションの流れを定義し、流れの中のやりとりであれば正常とみなす。
セッションの状態管理は、セッションIDというユニークな値で管理する。最初のレスポンスでセッションIDを発行し、クッキーに入れる。以降はセッションIDでやり取りを行い、機密情報はサーバ側で管理しておくことで、機密情報のやり取りが不要となる。また、ログインごとに異なるセッションIDを発行すれば、他人との区別も容易となる。

## LESSON5 アプリケーションの構成要素
アプリケーションの構成要素は、Webアプリケーションがサーバサイドでどのような処理がなされているかを知るために理解する必要がある。
サーバは1台？複数台？　複数台なら役割は？流れ方式？複数経路での分散処理？
### 5.1 WebサーバとWebクライアントの時代
詳細はLESSON2参照。
wwwの黎明期にクライアント・サーバシステムが構築され、後にCGIが誕生。
最初はサーバがCGIで別途Webアプリケーションを呼び出していたが、後にWebサーバ内にCGIの仕組みが取り込まれた。
### 5.2 データベースサーバの登場
コンピューター技術が進歩すると、次第に大量の蓄積データを管理する需要が生まれた。
そこでデータベースが開発された。データベース実現及び処理に特化した**データベース管理システム(DBMS)** が登場し、
コンピューター上でのデータ検索、保存、計算が容易となった。
データベースの種類と特徴→[NoSQL](https://hackmd.io/51gFU6EiTL2z0JNuwC8L8Q)
#### 5.2.1 RDBMSの基本操作と処理
多くは既知の内容のため、要点の記載のみに留める。
* CRUD
* CREATE（生成）
* READ（読み取り）
* UPDATE（更新）
* DELETE（削除）
* 正規化
* 情報を漏れなく記録する。
* 検索等の処理を考慮して適切にテーブルを分割する。
* 重複を排除する。
* SQL(Structured Query Langage)文
* CRUD順に並べたSQL文
* INSERT
* SELECT
* UPDATE
* DELETE
#### 5.2.2　データベースとクライアントとの関係
* データベースクライアント：人間が直接SQL文を打って、DBにアクセスする。直接コードを書くとハードコーディングが生じやすく望ましくない。
* ハードコーディング：変更する可能性のあるものを直接プログラムに書き込む行為。変更時にコードの書き換えが必要となるため避ける。
* アプリケーションプログラム：プログラムがSQL文を生成して、DBにアクセスする。DBの内容を変更してもプログラム内容は変化しないため望ましい。
#### 5.2.3　データベースサーバの分離
DBを用いたWebアプリケーション構造のうち最も単純なものは、Webサーバ内にDB領域を新設し、Webアプリケーションがそこにアクセスするものである。
Webサーバ内にDBを置くこの構造は、使用領域が大きくWebサーバに負荷がかかりやすい。
一般的にDBサーバはWebサーバから独立して持つ。この結果負荷分散が期待できるほか、既存システムとの結合にも役立つ。
（現在は仮想化やクラウド化が進み、領域を気にすることは殆ど無い？）
#### 5.2.4　データベースサーバとの通信
DBサーバとのやりとりはSQLを用いるが、その際の通信プロトコルはDB固有の通信プロトコルであることが多い。
多くはDBアクセス用のライブラリが提供される。

### 5.3 アプリケーションサーバの登場
LESSON2では、CGIの時代からJavaによるサーブレット・JSPの扱いを行えるようになった。
このサーブレットやJSPを動かすJVMは、アプリケーションサーバを介して動かしている。
CGIでは、Webサーバにリクエストが届く度に起動と終了を繰り返していたが、
アプリケーションサーバでは常に起動して、プロセスが常駐した状態となる。
アプリケーションサーバの代表例としてTomcatが挙げられる。WebサーバのApacheと連携して使用される。
#### 5.3.1 Webサーバとアプリケーションサーバの連携のメリット
アプリケーションサーバを使用した場合の処理は、Webサーバが窓口となりリクエストを受け取り、アプリケーションサーバへと転送する形となる。
アプリケーションサーバはWebサーバと分離することも可能である。
分離しておけば、静的で回数が多い処理をWebサーバ、動的で重い処理をアプリケーションサーバと役割分担でき、効率的な動作が可能となる。
また、1Webサーバから複数のアプリケーションサーバとも連携可能である。
#### 5.3.2 Web/アプリケーションサーバ
5.3.1のように機能分離を行うとシステムが複雑化し、準備や保守面で手間がかかる。
実は、Tomcat等のアプリケーションサーバは単独でWebサーバとしても利用できる。
アプリケーションサーバ内のWebサーバの機能を活用することで、システム構造が単純化し、設定も簡単になる。
但しWebサーバとしては最低限の機能しか持たないので注意が必要である。
**→小規模なアプリケーションや開発環境であれば、一体型のWeb/アプリケーションサーバを利用し、大規模なアプリケーションやWebサーバ固有の機能を利用したい時は、Webサーバとアプリケーションサーバを分離すると良い。**

### 5.4 Webシステムの三層構成
これまで登場したWebシステムの構成をまとめる。（凡例　＝：ノード間のつながり、－：ノード内のつながり）
クライアント、サーバ、DBの3つの役割に分けて連携させる構成を**三層構成**という。
* 最小構成（DBは他サーバと一体）
* クライアント ＝ アプリケーションサーバ（一体型） － DB 型　：一体型サーバを用いた最小限の配置
* クライアント ＝ Webサーバ － アプリケーションサーバ － DB 型　：Web・アプリサーバ分離型の配置
* 一般的な構成（DBは他サーバと分離）
* クライアント ＝ Webサーバ ＝ アプリケーションサーバ ＝ DB 型　：すべてのサーバが分離された配置
* データ特化型構成（DBのみ他サーバと分離）
* クライアント ＝ Webサーバ － アプリケーションサーバ ＝ DB 型　：DB以外は同一ノード。DBのみ分離の配置　大容量データシステム向け

###### tags: `読書`