#はじめに
この記事は、Webアプリケーション初学者のための、超大雑把な仕組みの説明になります。
「ドメイン？」「API？」「アプリケーションサーバ？」「サーバサイドレンダリング？」のように、
本を読んでも、そもそもの意味が頭に入ってこない。 もうだめだ....って方向けの記事になります。
超ざっくり説明している上に、もっとここ説明した方がいいだろ！！って部分もあると思いますが、
あくまで、Webアプリケーション初学者が、FE あるいは BE側の作業をやっていく上で、最低限知っておくべき
Webアプリケーションの知識という観点なので、悪しからず。
※図の作成は間に合わなかったので、今度付け足します。
#目次
1.Webアプリケーションって？
2.構成する要素（登場人物）の確認
3.それぞれの要素について
4.SSRとSPA
#1.Webアプリケーションって？
その名の通り「Webのアプリケーションです！」と言っても、抽象的すぎてイメージ湧かないですね。
このタイミングでは、必要知識が未だないという点もあるので、
相対する「ネイティブアプリ」と比較して、説明をしようと思います。
#####ネイティブアプリ
ネイティブアプリとは、一般的にはスマートフォン・PCにインストールされている
アプリケーションというイメージで良いです。
Androidのアプリなら、Google Playから。
iOSのアプリなら、App Storeから、「モンスト」だったり、「体重管理アプリ」
はたまた、「Google Map」、「Yahoo!JAPANアプリ」等をインストールできると思います。
上記のようなアプリは、インストールを必要とする反面
インストールしてしまえば、いつでもOS上で起動できるアプリケーションだと思います。
ネットワークに繋がっていなくても、アプリケーションの起動は行えますし、サーバとの通信が不要なものは
いつでもどこでも起動して、使えます。
このような、「インストールは必要だけど、アプリケーションの実体を端末に入れてしまえば、起動・動作がいつでもできるアプリケーション」を
ネイティブアプリと捉えていいかと思います。
#####Webアプリケーション
ネイティブアプリに対して、Webアプリケーションは
・ネットワーク環境が必ず必要
・画面表示を担うのは、Webブラウザ（IE,Chrome,safari...etc)になります。
....これでは、あまりに抽象的すぎるので、もう少し具体的に説明していきましょう。
Webアプリケーションを知るには、もう少しWebブラウザをはじめとした ネットワーク上の登場人物を
理解しておく必要があるので、
「Webアプリケーション全体の構成要素」を確認していきましょう。
#2.構成する要素（登場人物）の確認 （図、用意中）
Webアプリケーションの中に出てくる、登場人物を分類わけして表現していきましょう。
※ここでは一旦SSR(サーバサイドレンダリング)パターンで、解説します。
後から、SPA（シングルページアプリケーション）についても追記します。
◽️一般のユーザの方々
・Webブラウザ
◽️一般ユーザ（ブラウザ） と サーバサイドをつなぐ要素（インターネットの層）
・DNS （図は右記がわかりやすい：https://webtan.impress.co.jp/e/2011/11/25/11551）
・HTTP通信／HTTPS通信
|-HTTPメソッド
|-リクエストヘッダ／ボディ
|-レスポンスステータスコード／ボディ
◽️サーバサイド（いわゆるBEエンジニアが作るもの）
（htmlテンプレートは、FEエンジニア）
・HTMLファイル（HTMLテンプレート）
・Webサーバ
・Webアプリケーションサーバ
#3.それぞれの要素について
#####一般ユーザ側の登場人物
#####Webブラウザ
一般的には、みなさんがググる時に使ったりしている、
「chrome」、「IE」、「edge」、「firefox」...etcのような、
Webページを閲覧しているツールのことです。
今回知って欲しいのは、Webブラウザは一体何ができるツールなのか？という点です。
Webブラウザは、大きく分けると２つの機能を持っています。
①HTMLのファイル（および CSS や javascript）を解析して、画面描画する機能。
②HTMLファイルを取得するために、Webサーバに対してHTTPの通信を行う機能。（SPAの場合は、若干表現が誤ってるが、一旦現段階の説明のため）
①から分かることは、
皆さんがいつもWebで閲覧しているサイトの描画は、 どこかからHTMLファイルを取得して、それを描画しているということ。
②から分かることは、
画面描画するためのHTMLファイルを、Webサーバから取得する通信を担っているということ。
（みなさんが、googleのtopページに行く場合は、 URLに 「https://www.google.com/」と打ち込んでるはずですが、
これも同じくWebサーバへの通信を行って、 HTMLファイルを取得し、 画面描画している といった動きになります）
これらのブラウザの動きを軸に、HTMLファイル取得までの流れ（Webアプリケーション）の解説をしていきます。
#####一般ユーザ（ブラウザ） と サーバサイドをつなぐ要素（インターネットの層）
#####DNS
DNS・・・ドメインネームシステムの略です。
いや、なんのシステムやねん。って話なのですが。笑
ここを軽く説明していきますorz
※今回、IPv4,IPv6,グローバルIP、プライベートIP、固定IP周りに関しては触れず、
あくまで、対象のサーバが XXX.XXX.XXX.XXXの固定IPアドレスを持ってると仮定して説明します。
前提として知っておかなければならないのは以下の1つ
・インターネット上で、通信を行う端末には、必ずIPアドレスが割り当てられている（みなさんのPCもそうだし、 Webサーバもそう）
はい、前段はここまでとして。
ざっくり言うと、ドメインとはIPアドレスを人用に分かりやすく文字列にしたもの という認識で良いと思う。
上記にも書いたように、全てのWebサーバ（いわゆる googleのサーバや amazonのサーバ等 あらゆるWebサーバ）は
IPアドレスを持っています。
なので、Webブラウザで http://XXX.XXX.XXX.XXX と打つと、当然該当のIPのWebサーバに通信ができます。
この時、このIPがWebサーバなのならば、HTMLファイルを返してくれるでしょう。
ただ、普段IPアドレス（数字だけ）で、URL書いたりしないですよね？
kakaku.com だったり www.google.com のように、文字列で表現していますよね。
これこそが、IPアドレスを代替してくれる文字列＝ドメインです。
では、ブラウザで「http://XXX.XXX.XXX.XXX」に接続した場合、どんな動きをするのか？
以下のように、分散型のサーバの仕組みを使って、IPアドレスを探しにいきます。
この分散型のサーバで構成された、ドメインからIPアドレスを探しあてる仕組みを DNSと呼び、
それぞれのサーバのことをDNSサーバと言います。
図からも分かるように、
DNSサーバには IPとドメインの紐つけが登録されていたり、
ドメインのDNSサーバ名が記載されていたりします。
※元々はhostsファイルは、この仕組みの前段だったことや、
DNSレコードの、”Aレコード”、"CNAME"等についてはいずれ）
今回は、ドメインから、webサーバ（IPアドレス）にたどり着くことができるよ、が分かればOK。
#####HTTP通信／HTTPS通信
これは、ブラウザ↔︎Webサーバ間の通信方式の総称のことです。
この通信方式の中での、細かな仕様はこの後説明します。
ここでは、
・HTTP通信・・・通常の通信
・HTTPS通信・・・暗号化した通信
であることを意識しておいてください。 今回はここだけ理解でOK。
余談ですが、
数年前から、HTTPS通信であることが、googleの検索上位ヒット（SEO)の一つの評価にもなっていることから、
HTTPS通信にすることが推奨されています。
が、これを満たすには、 SSLサーバ証明書 を取得する必要があリます。
例えば以下のような感じで、証明書のレベル具合によって値段も変わってきます。
https://jp.globalsign.com/service/ssl/products_price/
#####HTTPメソッド（HTTP通信／HTTPS通信）
HTTP通信としては、以下のようなメソッドで通信ができます。
https://developer.mozilla.org/ja/docs/Web/HTTP/Methods
一般的に、みなさんが単純にWebで検索をしたり、URL欄にURLをうって画面表示している時は、
GETメソッドで通信（リクエスト）を飛ばしています。
Webサーバ側は、GETメソッドの時は、こんなHTMLファイルを返すんだよ〜という機能を実装しておくことで、
ユーザ側にHTMLを返すことができます。
ここで注意して欲しいのは、
POSTや、PUT、PATCHのように、 ”部分更新（更新）” や ”全体の置き換え（登録）”を意識したメソッド達がいますが、
これらはあくまで、上記のような思想で利用してくださいという思想です。
例えば、PATCHは”部分更新”といった意味合いがイメージですが、
ブラウザ＝＞Webサーバに PATCHで通信が飛んできたときに、データを全部削除してね〜という実装をWebサーバにしておけば、
PATCHでデータを削除することもできます。
ここで言いたいことは、それぞれのHTTPメソッドに対応した処理を作成するのは、
Webサーバ側と言うことです。 どんなにブラウザから、PATCHです〜 PUTです〜という通信をWebサーバに投げても、
Webサーバ側がHTTPメソッドの対応する、適した実装をしておかなければダメです。
（BE側のエンジニアは、このHTTPメソッドと、 実際の機能の紐つけを適当にやらないように！）
#####リクエストヘッダ／ボディ
HTTP通信の中で、ブラウザ＝＞Webサーバに上記のHTTPメソッドで通信する際、
リクエストヘッダ／ボディ と言うものが通信の中で飛んでいます。
webサーバ側は、このデータを元に登録処理等をしていきます。
リクエストヘッダには、基本的に追加情報（付加情報）が含まれています。
いろんなものが送れますが、代表的なものでいくと以下のようなものです、
Accept・・・Webサーバから返却される際に受け取れる形式
例）text/html
リクエストボディには、Webサーバに送る情報そのものです。
例えば、Webブラウザの画面で”名前欄”という入力フォームがあって、
送信ボタンを押した際に、名前を登録する昨日だったとしましょう。
この場合、送信ボタンを押された際には、POSTメソッドで通信が発生し
その時のリクエストボディの中身には、 名前欄に入力した 値 が入っているイメージです。
※「POSTで飛んできた時、リクエストボディ内の値を登録する」という機能を Webサーバに用意しておけば登録が可能です。
そして「POSTで飛んできた時、リクエストボディ内の値を登録する」 これこそが、APIそのものになります。
#####レスポンスステータスコード／ボディ
こちらは、Webサーバでの処理が終わった後、
Webサーバから、ブラウザに対して情報を返す時の情報群になります。
レスポンスステータスコードと言うのは、処理の結果を体系的にコードで表したものです。
これもHTTPメソッドと同じように、デタラメなもので返すことも可能ですが、
返すべきコードで返すようにしましょう。
（これに関してもBEエンジニアは、迷った際はプロジェクト方針と、フロント側でのエラーハンドリング方針も意識しておくこと）
レスポンスボディは、それこそ今回の場合はHTMLファイルそのものになります。
ブラウザからリクエストが飛んできて、 それに対する返却値が HTMLファイルとなる。 この、HTMLファイルをレスポンスボディで返しています。
はい。ちょっと説明の合間合間に、サーバ側の話まで及んでしまっていましたが、
最後は、サーバサイド側の説明になります。
#####サーバサイド（いわゆるBEエンジニアが作るもの）
#####HTMLファイル
これは、HTMLのフォーマットに則って作られたファイルのこと。
このファイルをブラウザに読み込ませることで、画面描画が可能になります。
このHTMLファイルを作成したり、CSS等でデザイン調整を行うのは、
FEエンジニアの仕事となります。
thymeleaf(JSPもかな？)の場合は、このHTMLの記述の中に、
動的な値を記述することができ、その動的な値に サーバサイドプログラムで作った値を
連携することで、 プログラムに則った、動的な画面を作成することが可能です。
この、「動的な値を記述する」など、HTMLテンプレートに手を加えていく部分は、
一般的にはBEエンジニアの仕事になるかと思います。
#####Webサーバ
ここが一番間違われやすいもの。
よくTomcat(WEBアプリケーションサーバ）と混同されがちで、初学者を惑わせる原因になると思ってます。
ここは言葉をきちんと使い分けていきましょう。
Webサーバとは何ぞや？なのですが、簡単に言ってしまうと
これまでに説明してきた、ブラウザからのHTTP通信を受けることのできるサーバのことです。
んー。。しっくりこないかもしれません。
表現を変えましょう。
ブラウザ ＝＞ あなたのお使いのPC（IP）に HTTP通信は行えますか？
答えはNOです。何故ならば、Webサーバじゃないから。
じゃあ、どうやったら、Webサーバになれるのか？ どうやったらHTTP通信を受けることができるようになるのか？
答えは、「Webサーバになる為の ソフトウェアをコンピュータにインストールする」です。
ここで出てくる、ソフトウェアがかの有名な「Apache (Apache HTTP Server）」 や 「nginx」になります。
これをインストールすることで、初めてHTTP通信を受け取る Webサーバになることができます。
結果としては、「Webサーバとは、 Webサーバ用ソフトウェアをインストールして、稼働しているコンピュータ」のことです。
#####Webアプリケーションサーバ
Webサーバの中に、構築されているのが Webアプリケーションサーバという認識で良いです。
Webサーバが、単純にHTTP通信として、リクエストを受け取るのに対して、
それぞれのHTTPメソッドに応じたサーバサイド側のプログラム（API）を作っておいて、
プログラミング言語に対応した処理を行うのが、Webアプリケーションサーバになります。
有名なもので行くと、JavaのWebアプリケーションサーバ「Apache Tomcat」です。
あれ？Javaのwebアプリケーションサーバがあるということは....
そうです。 他の言語用のwebアプリケーションサーバもあります。（私は使ったことないですが）
例えば、Webサーバで説明した、「nginx」に対応した、 Python、Go、Perl、Ruby、PHP等の言語で利用できる
Webアプリケーションサーバ「NGINX Unit」があったりします。
はい、図ができてないので、ホワイトボードに書きながら説明するしかないですが。笑
一旦Webアプリケーション全体像のお話はできたかと思います。
最後に少しだけ、SPAの話をしましょう。
#4.SSRとSPA
ここまで、SSR（サーバサイドレンダリング）を軸に話をしましたが、
SPAについても話をしておきましょう。
#####SSR
ここまで説明してきたように、
ブラウザから、HTTP通信（GETとかPOSTとか）をWebサーバに送りつけることで、
それぞれのアプリケーションサーバの中で処理を行い、 最終的にHTMLファイルを返却してもらい、画面描画する流れでした。
はい、何か問題でも？といったところかと思います。
サーバ側に処理が集中するものの、ロジック等の処理全て含めてサーバ側で行うので、
処理自体は高速に行えて、素早くhtmlファイルを作成しブラウザに返すことができます。
なので、ユーザの端末がゴミスペックだろうが、高スペックだろうが、描画自体にあまり差異が出ることはありません。
ただ一つ古臭いなと思う点があります。
ページに接続した時、更新ボタンを押した時、次へボタンを押した時、カテゴリを変えた時....それぞれ
Webページで何らかのアクションを起こすたびに、ページが再描画されます。（一瞬画面が真っ白になったりしますよね）
いやぁ、ページ遷移（再描画もせず）せず、実現できたらモダンだなと。。。
これを実現するのがSPAです。
#####SPA （ここ図がないとキツイので、絶対追加）
これまで、サーバサイド側は、「HTMLを返す！」といい続けましたが、SPAでは異なります。
これまで同様、各画面の初期描画時（例えば、ホーム画面、商品選択画面...etc)は、htmlを返します。
しかし異なる点はここから。
例えば、カテゴリをAからBに変更したとしましょう。（図がないときついな）
今表示している画面に、色々なコンテンツがあるとして、
今回描画し直したいのは、カテゴリの部分だけである。といった場合に、SSRでは他コンテンツ含めて全ての情報をもう一度取得し直して、
画面描画を行います。
それに対し、SPAではカテゴリの情報だけを返してくれる機能をサーバサイド側に作っておき、
画面でカテゴリを変更された場合は、javascriptでサーバサイドにカテゴリ情報を取得する機能を呼び出します。
この時、データのレスポンスは、「HTML」ではなく、「jsonやxml」で受け取ることで、 画面側の実装で部分的なコンテンツの描画し直しができます。
これがSPAの良さです。
と言いたいところですが、全く言いたいことが表現できてないので書き直します。笑
一旦今日はここまで。