概要
AngularでWebシステムを開発する前提として、Webアプリの基本構成、クライアントサイド、サーバーサイド、HTTPリクエスト、HTTPレスポンスの流れを整理する。
Angularはフロントエンド側のフレームワークだが、実際のWebシステムではサーバー、データベース、HTTP通信と連携して動く。全体像を先に押さえておくと、Angularの役割を理解しやすくなる。
ここでは、Webブラウザから要求が送られ、サーバーで処理され、HTMLやデータが返ってくるまでの流れを確認する。
この記事の構成
- 対象環境と利用上の注意
本文記載時の環境と現在そのまま利用できない箇所を確認。 - 学習前に確認すること
以降の説明に必要な用語とシステム構成の前提を確認。 - Webシステムとは
Webシステムの意味と基本的な考え方を整理。 - クライアントサイドとは
クライアントサイドの意味と基本的な考え方を整理。 - サーバーサイドとは
サーバーサイドの意味と基本的な考え方を整理。 - HTTPリクエスト
HTTPリクエストの意味と要点を具体例から整理。 - HTTPレスポンス
HTTPレスポンスの意味と要点を具体例から整理。 - Webシステム全体の処理フロー
Webシステム全体の処理フローを順にたどり、各処理の役割を整理。
対象環境と利用上の注意
- 本文記載時の環境
Angular CLI 13.2.0、Node.js 16.13.1、npm 8.3.2、TypeScript 4.5.5、Windows x64と、NgModuleベースの生成構成を前提とした2021〜2022年当時の説明。 - 確認時期
2026年8月。HTTP仕様とAngular公式資料を照合して記載内容を見直した。
掲載した画面や手順は現行環境で再実行していない。 - 現在そのまま利用できない箇所
現在のAngular CLIはstandalone APIを使うアプリケーションを標準で生成する。
後続記事のAppModuleを使う構成は、既存のNgModuleベースのアプリケーションを読むための旧構成例として扱う。
学習前に確認すること
| 確認項目 | 内容 |
|---|---|
| 前提知識 | HTML、CSS、JavaScriptがブラウザで動くことを大まかに知っておく。 |
| 通信の見方 | 画面操作の裏側ではHTTPリクエストとHTTPレスポンスが行き来する。 |
| Angularの位置付け | Angularは主にクライアントサイドの画面制御を担当する。 |
Webシステムとは
Webシステム(Webアプリ)は、Webブラウザ上で利用できるサービスやそのシステムの総称を指し、次項で示す クライアントサイドとサーバーサイド間をHTTP通信(通信プロトコル)を用いてやり取りする。
このやり取りについては、次項で示すHTTPリクエスト(ユーザーの要求情報)、HTTPレスポンス(サーバーの応答結果)のデータ構造で送信され、クライアント/サーバー間のインターフェースとして重要な役割を持つ。
※ Webブラウザではなく、ユーザー端末用のソフトウェアをインストールしてサーバー間通信を行うクライアントサーバーシステム(C/Sシステム)と混同注意。
また、Webシステムには、以下のメリット、デメリットがある。フレームワークは一部の問題への対策を支援するが、開発者はセキュリティ、性能、ブラウザ互換性、アクセシビリティなどを設計時に確認する必要がある。
-
ユーザー側のメリット
通信環境とWebブラウザのみで利用でき、特別なソフトウェアのインストールが不要。
PC、タブレット、スマートフォンなど幅広い端末で同時に利用できる。
バージョンアップの際、ユーザー側の負担が少ない。
ブラウザの推奨バージョンが上がった場合は、ブラウザの最新化が必要。 -
運用側のメリット
検索エンジンからダイレクトに新規ユーザーのアクセスを受け入れられる。
WebシステムのURLやQRコードのみのシンプルな広告を出せ、SNSでも拡散されやすい。
ユーザー端末に特別なソフトウェアが不要なため、初期設定やバージョンアップ時のプログラム配布コストがない。 -
ユーザー側のデメリット
多くのWebシステムは通信できない環境では利用できない。ただし、Service Workerなどを用いて一部機能をオフライン対応させる構成もある。
通信速度が回線やユーザー端末の性能に左右され、システム利用に大きな支障をきたす場合がある。 -
運用側のデメリット
外部からのハッキングやデータ改ざん、不正アクセスなどあらゆるセキュリティ攻撃を想定し、万全なセキュリティ対策を徹底しなければならない。
ユーザーの同時アクセスにより、サーバーに負荷が集中するため、アクセス数を明確に見越したサーバー設計(マシン構成や負荷分散)が必要。
Webブラウザの仕様制限でWebシステムの柔軟な開発ができない。
WebブラウザやOS依存の個別対応が必要。
ユーザー端末に内蔵されているカメラ機能、GPS機能、プッシュ通知機能などのネイティブ機能は、セキュリティ面からできることが限られている。
開発方針や開発言語の技術進歩が速いため、学習コストが高く、有識者の確保が困難。
クライアントサイドとは
クライアントサイドとは、ユーザー端末のWebブラウザなど、クライアント側で実行される処理を指す。画面を構成する領域は、一般にフロントエンドとも呼ばれる。
Webブラウザは、HTTPレスポンスとして受け取ったHTMLを解析し、必要に応じてCSSやJavaScriptを別のHTTPリクエストで取得する。Angularアプリケーションは、取得したJavaScriptがブラウザ上で実行され、画面表示や操作を制御する。
※ 実行タイミングは、次項Webシステム全体の処理フローの(2)、(3)、(14)、(15)を参照。
-
HTML(Hyper Text Markup Language)
Webページ作成(文書を保管・閲覧する)のために開発されたマークアップ言語でテキスト、音声、画像、動画、データファイルなどの表示やリンクを埋込むことができる。※ HTMLの規格やHTMLの前進となったマークアップ言語については、下記を参考。
応用情報技術 - プログラム構造・言語:HTML(HyperText Markup Language) -
CSS(Cascading Style Sheet) 文章やタグなどの要素をどう見せるかそのスタイルを定義するために作られた言語で、HTMLやXHTMLで使用される。
また、Webページでは、要素の構造と体裁は、分離する理念(方針)があるため、構造は、HTMLに、体裁は、CSSに記述。※ XHTMLについては、下記を参考。
応用情報技術 - プログラム構造・言語:XHTML(Extensible HTML) -
JavaScript
主要なWebブラウザが実行環境を備えるプログラミング言語で、キーボードやマウス操作などのイベントに応じた画面制御や動的処理を実装できる。
大規模なフロントエンド開発では、開発効率や保守性を高めるためにフレームワークやライブラリを利用することが多い。代表例として、次の技術がある。- Angular(アンギュラー)
主にTypeScriptを使用するWebアプリケーションフレームワーク。 - React(リアクト)
JavaScriptやTypeScriptでユーザーインターフェースを構築するライブラリ。 - Vue.js(ビュージェイエス)
JavaScriptやTypeScriptを使用できるフレームワーク。
- Angular(アンギュラー)
サーバーサイドとは
サーバーサイドとは、クライアントサイドから送信された要求を受け付け、必要な処理を行って応答を返す領域を指す。一般にバックエンドとも呼ばれる。
サーバーサイドは、役割としてWebサーバー、APサーバー、DBサーバーなどに分けて考えられる。これらは必ず3台の物理サーバーへ分けるものではなく、一台へまとめる構成や、複数台・クラウドサービスへ分散する構成もある。
サーバーサイドのメイン処理は、次のサーバーサイドプログラムで実行され、次項Webシステム全体の処理フローのAPサーバー(アプリケーションサーバー)上で動いている。
※ 実行タイミングは、次項Webシステム全体の処理フローの(6)、(7)、(10)、(11)を参照。
以下、利用率・評価が高いプログラム言語のみ抜粋。
-
Python
簡潔なプログラム構文で書きやすく読みやすいインタプリタ型言語(*1)で人工知能や深層学習のデータ解析で広く使われている。
代表的なフレームワーク:Django、Bottle、Flask、Tornado、Plone -
PHP
Webシステム・サービス開発に特化したインタプリタ型言語(*1)
代表的なフレームワーク:Laravel、Symfony、CakePHP、CodeIgniter、Zend Framework -
Ruby
日本で開発されたオブジェクト指向型(*2)のインタプリタ型言語(*1)
代表的なフレームワーク:Ruby on Rails、Sinatra、Padrino、Ramaze、HANAMI -
Java
オブジェクト指向型(*2)のコンパイラ型言語(*3)でWebシステムだけなく、組込み/制御系やAndroid開発など幅広い分野で利用されている。
代表的なフレームワーク:Spring Framework、Play Framework、JSF、Spark Framework、Apache Struts -
C#
Javaと同様に幅広い分野で利用されているオブジェクト指向型(*2)のコンパイラ型言語(*3)
代表的なフレームワーク:ASP.NET Web Form、ASP.NET MVC -
(*1)インタプリタ型言語
実行環境がソースコードや中間表現を読み取りながら処理する実行方式。実装によっては事前コンパイルやJITコンパイルも使われるため、言語名だけで実行速度は決まらない。 -
(*2)オブジェクト指向
応用情報技術 - プログラム構造・言語:プログラム言語の変遷を参考。 -
(*3)コンパイラ型言語
実行前にソースコードを機械語、バイトコード、JavaScriptなどの別の表現へ変換する方式。コンパイルとデプロイは別工程であり、変換先や実行方法は言語・処理系によって異なる。
HTTPリクエスト
HTTPリクエストは、要求先や要求方法に加えて、受け入れ可能なメディアタイプ、認証情報、必要に応じた送信内容などを伝える。HTTP/1.1のメッセージは、リクエストライン、0個以上のフィールド行、フィールド部を終える空行、必要に応じたメッセージ内容の順に記述される。
※ HTTP/1.1では、リクエストライン、フィールド行、空行(CRLF)、任意のメッセージ内容の順に送る。HTTP/2やHTTP/3はバイナリ形式で表現するため、同じ行形式ではない。
-
リクエストライン
下記の \(3\) 項目を半角スペース区切りで並べたデータフォーマットで、[リクエストメソッド] [URI] [プロトコル]となる \(1\) 行のデータで記述される。-
リクエストメソッド
新規データを送信するPOST(データ登録)、指定した情報を取得するGET(データ取得)、更新データを送信するPUT(データ登録/更新)、指定した情報を削除するDELETE(データ削除)など、要求内容に合ったメソッドを指定。 -
URI
リクエストメソッドを要求するURI(URIは、広義の意味を持つがこの場合、サーバーサイドのどのプログラムに要求するか場所を特定するためのURLの一部を指定する)を指定。 -
プロトコル
HTTPリクエストのプロトコル「HTTP」とそのバージョンを指定。
このバージョンによって、リクエストメソッドで指定できるメソッド仕様も変化するが、上記で記載したPOST、GET、PUT、DELETEの使用頻度が高い基盤となるメソッドについては、変化がないため厳密に意識する必要はない。 -
例 : POST時のリクエストライン
POST /detail/example/ HTTP/1.1 -
例 : GET時のリクエストライン
GET /index.html HTTP/1.1
-
-
リクエストヘッダー
項目名と値をコロンで区切ったフィールド行を並べる。RFC 9110では、旧仕様の「ジェネラルヘッダー」「リクエストヘッダー」「エンティティヘッダー」という分類を使わず、各フィールドの意味と適用対象を個別に定義している。以下は仕様上の分類ではなく、役割ごとに整理した代表例となる。-
メッセージ転送やキャッシュに関する代表的なフィールド
Date : HTTPリクエストの作成日時。
Pragma : キャッシュ許容などの通信オプション。
Cache-Control : キャッシュ制御に必要な指示や情報。
Connection : 現在の接続だけに適用する通信オプション。
Transfer-Encoding : HTTP/1.1メッセージを転送するための符号化方式。
Via : クライアント/サーバー間の転送経路。
など -
リクエストに関する代表的なフィールド
Authorization : サーバーからの認証要求に応じて、クライアントが資格情報を送るためのフィールド。
From : ユーザーのメールアドレス。
Referer : 前回ページを取得した時のページURL。
User-Agent : Webブラウザの固有情報。
Accept : Webブラウザが受入可能なMIME(メディアタイプ)。
Accept-Charset : Webブラウザが受入可能な文字セット。
Accept-Encoding : Webブラウザが受入可能なエンコーディング方法。
Accept-Language : Webブラウザが受入可能な言語コード。
など -
メッセージ内容に関する代表的なフィールド
Content-Encoding : メッセージ内容へ適用した符号化方式。
Content-Language : メッセージ内容の言語。
Content-Length : メッセージ内容の長さ。
Content-Type : メッセージ内容のメディアタイプ。 -
例 : GET時のリクエストヘッダー
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9 Accept-Encoding: gzip, deflate, br Accept-Language: ja-JP,ja;q=0.9,en-US;q=0.8,en;q=0.7 Connection: keep-alive Referer: https://sigma-se.com/ User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.45 Safari/537.36 Host: sigma-se.com Pragma: no-cache -
例 : POST時のリクエストヘッダー
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-powerpoint, application/vnd.ms-excel, application/msword, */* Accept-Language: ja-JP,ja;q=0.9,en-US;q=0.8,en;q=0.7 Accept-Encoding: gzip, deflate, br Referer: https://sigma-se.com/ User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.45 Safari/537.36 Host: sigma-se.com Pragma: no-cache Content-Type: application/x-www-form-urlencoded Content-Length: 57
-
-
リクエストボディ
リクエストのメッセージ内容を記述する領域。POSTなどで送信データを格納する場合があるが、メソッド名だけで有無は決まらず、内容を持たないリクエストもある。- 例 : POST時のリクエストボディ
useraccount=user@example.com&name=example&comment=sample
- 例 : POST時のリクエストボディ
HTTPレスポンス
HTTPレスポンスには、HTTPリクエストに対するサーバーの応答結果が記述される。HTTP/1.1のメッセージは、ステータスライン、レスポンスフィールド、フィールド部を終える空行、必要に応じたメッセージ内容で構成される。
※ HTTP/1.1では、ステータスライン、フィールド行、空行(CRLF)、任意のメッセージ内容の順に送る。HTTP/2やHTTP/3はバイナリ形式で表現するため、同じ行形式ではない。
-
ステータスライン
下記の \(3\) 項目を半角スペース区切りで並べたデータフォーマットで、[プロトコル] [ステータスコード] [テキストフレーズ]となる \(1\) 行のデータで記述される。-
プロトコル
HTTPレスポンスのプロトコル「HTTP」とそのバージョンを指定。 -
ステータスコード
リクエストに対するサーバーレスポンスの状態を表す数字3桁のコードで、下記5つに大別される。- \(100\)番台 : サーバー処理継続状態などの情報レスポンス
- \(200\)番台 : サーバー処理が成功した場合のレスポンス
- \(300\)番台 : リクエスト応答の必要な追加情報や応答の状態を示すレスポンス
- \(400\)番台 : クライアントサイドのエラーレスポンス
- \(500\)番台 : サーバーサイドのエラーレスポンス
※ 詳細なエラーコードについては、下記を参考。
Internet Assigned Numbers Authority, Hypertext Transfer Protocol(HTTP)Status Code Registry
-
テキストフレーズ
ステータスコードの概要が記述される。 ステータスコードが \(200\) である場合の\(OK\)や \(404\) である場合の\(Not Found\)など。 -
例 : ステータスコードが \(200\) のステータスライン
HTTP/1.1 200 OK -
例 : ステータスコードが \(404\) のステータスライン
HTTP/1.1 404 Not Found
-
-
レスポンスヘッダー
項目名と値をコロンで区切ったフィールド行を並べる。RFC 9110では、旧仕様の「ジェネラルヘッダー」「レスポンスヘッダー」「エンティティヘッダー」という分類を使わず、各フィールドの意味と適用対象を個別に定義している。以下は仕様上の分類ではなく、役割ごとに整理した代表例となる。-
メッセージ転送やキャッシュに関する代表的なフィールド
- Date : HTTPレスポンスの作成日時。
- Pragma : キャッシュ許容などの通信オプション。
- Cache-Control : キャッシュ制御に必要な指示や情報。
- Connection : 現在の接続だけに適用する通信オプション。
- Transfer-Encoding : HTTP/1.1メッセージを転送するための符号化方式。
- Via : クライアント/サーバー間の転送経路。
- など
-
レスポンスに関する代表的なフィールド
レスポンスの追加情報やサーバーサイド固有の情報を付与するためのヘッダー。- Location : リダイレクト先などを示すURI参照。相対参照も指定できる。
- Server : Webサーバーのサーバー名やバージョンなどサーバー固有の情報。
- WWW-Authenticate : サーバーがクライアントへ提示する認証方式と認証領域などのチャレンジ情報。
- Age : キャッシュされたレスポンスが生成または再検証されてからの推定経過秒数。
- Proxy-Authenticate : プロキシサーバーがWebブラウザに要求するユーザーの認証情報。
- Retry-After : Webサーバー側の停止によるリクエスト再試行までの待機時間を指定。
- など
-
メッセージ内容に関する代表的なフィールド
- Content-Encoding : メッセージ内容へ適用した符号化方式。
- Content-Language : メッセージ内容の言語。
- Content-Length : メッセージ内容の長さ。
- Content-Type : メッセージ内容のメディアタイプ。
- Last-Modified : 対象リソースの最終更新日時。
- など
-
例 : GET時のレスポンスヘッダー
Date: Fri, 10 Dec 2021 13:59:33 GMT Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips mod_wsgi/4.6.2 Python/3.6 Accept-Ranges: bytes Content-Length: 25759 Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Content-Type: text/html; charset=utf-8 Strict-Transport-Security: max-age=315360000; Vary: Cookie X-Frame-Options: SAMEORIGIN
-
-
レスポンスボディ
HTTPリクエストに対するメッセージ内容を格納する。内容はHTMLに限らず、JSON、画像、動画、PDFなどの場合があり、204レスポンスやHEADへの応答など、内容を持たない場合もある。- 例 : HTMLを返すGET時のレスポンスボディ
<!DOCTYPE html> <html lang="ja"> <head> <!-- Required meta tags always come first --> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no"> <meta http-equiv="x-ua-compatible" content="ie=edge"> <!-- Bootstrap CSS --> <link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/4.0.0-alpha.4/css/bootstrap.min.css" integrity="2hfp1SzUoho7/TsGGGDaFdsuuDL0LX2hnUp6VkX3CUQ2K4K+xjboZdsXyp4oUHZj" crossorigin="anonymous"> <!-- Menu --> <meta name="msapplication-config" content="/static/macuos/img/fav/browserconfig.xml" /> <meta name="msapplication-TileColor" content="#ffffff"> <meta name="msapplication-TileImage" content="/static/macuos/img/fav/mstile-144x144.png"> <meta name="theme-color" content="#f5deb3"> <link rel="icon" type="image/x-icon" href="/static/macuos/img/fav/favicon.png"> <link rel="apple-touch-icon" sizes="180x180" href="/static/macuos/img/fav/apple-touch-icon-180x180.png"> <link rel="mask-icon" href="./safari-icon.svg" color="#555" /> <link rel="icon" type="image/png" sizes="192x192" href="/static/macuos/img/fav/android-chrome-192x192.png"> <!-- <link rel="manifest" href="https://sigma-se.jp/img/fav/manifest.json"> --> <!-- Src Disp : highlight Var 9.13.0--> <link rel="stylesheet" href="/static/macuos/a11y-dark.css"> <script src="/static/macuos/highlight.pack.js"></script> <script>hljs.initHighlightingOnLoad();</script> <!-- SNS Other --> <meta property="og:url" content="https://sigma-se.com" /> <meta property="og:type" content="article" /> <meta property="og:title" content="SIGMA-SE Math & Tech Library" /> <meta property="og:description" content="Engineer Math & Tech Library" /> <meta property="og:image" content="/static/macuos/img/sigma-se2.jpg" /> <meta property="author" content="SIGMA-SE Math & Tech Library" /> <!-- SNS Buttom--> <link rel="stylesheet" href="/static/macuos/sns-icon.css"> <link rel="stylesheet" href="/static/macuos/sns-style.css"> <link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Lato:400,700,900"> <link rel="stylesheet" href="/static/macuos/icomoon.eot"> <link rel="stylesheet" href="/static/macuos/icomoon.svg"> <link rel="stylesheet" href="/static/macuos/icomoon.ttf"> <link rel="stylesheet" href="/static/macuos/icomoon.woff"> <!-- MathJax --> <script type="text/javascript" async src="https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.4/MathJax.js?config=TeX-MML-AM_CHTML"></script> <!-- Custom CSS --> <link rel="stylesheet" href="/static/macuos/base.css"> </head> <body> ... </body> </html>
Webシステム全体の処理フロー
Webシステムにおける主要な処理やデータの流れを、次のフローで整理する。
- Webシステム全体の処理フロー
- (1)ユーザーの要求情報を入力
Webブラウザに対して、サイトマップやメニュー、リンク、ボタンなどのクリックによる操作で、画面遷移や検索、登録、更新、削除などのユーザー要求を入力。 - (2)クライアントサイドプログラムがHTTPリクエストを生成
(1)の要求情報に応じたHTTPリクエストをクライアントサイドプログラムが生成。
このとき、実行されるクライアントサイドプログラムは、下記(13)でWebサーバーから返却されるJavaScriptが主体となる。 - (3)サーバーサイドにHTTPリクエストを送信
(2)で生成したHTTPリクエストをHTTP通信でWebサーバーに送信。 - (4)リクエスト受信とコンテンツ分類
(3)のHTTPリクエストを受信し、静的 or 動的コンテンツを分類。 - (5)動的コンテンツを要求
Webサーバーに構築されているソフトウェア(Nginx、Apache、LiteSpeed、Microsoft-IISなど)が(4)で分類した動的コンテンツをAPサーバーに要求する。 - (6)要求条件をデータベース命令に変換
APサーバーに構築されたサーバーサイドプログラム(Python、PHP、Ruby、Java、C#など)が、(5)の動的コンテンツ生成に必要な条件を整理し、データベースに対して命令(処理要求、問合わせ)を行うSQLに変換。
SQLについては、下記を参考。
応用情報技術 - データベース(データ操作):SQL - (7)データの実行命令
(6)で生成したSQL(取得/登録/更新/削除要求)をDBサーバーに発行する。 - (8)データベースに対し命令を実行
DBサーバーに構築されたソフトウェア(Oracle、PostgreSQL、SQLServer、MySQLなど)が(7)のSQLを実行し、データベースからデータ抽出、または更新を行う。 - (9)命令の実行結果を返却
SQLの実行結果をAPサーバーに返す。 取得要求なら抽出データ、登録/更新/削除要求なら処理件数など成功 or 失敗を判断できるデータを返す。 - (10)データベースの結果に応じた動的処理を実行
(9)の結果を必要に応じて加工し、Webサーバーに返却する動的コンテンツ(加工により静的コンテンツとなる)を生成。 - (11)動的コンテンツの返却
(10)の静的コンテンツを動的コンテンツの要求結果として、Webサーバーに返却。 - (12)HTTPレスポンスを生成
(11)の結果を元に、ステータスコード、レスポンスフィールド、HTMLやJSONなどのメッセージ内容を生成。 - (13)クライアントサイドにHTTPレスポンスを返却
(12)のHTTPレスポンスをWebブラウザへ返却。HTMLから参照するJavaScriptやCSSは、HTML内に直接記述される場合と、別のURLから追加取得される場合がある。 - (14)HTTPレスポンスの受信と画面の構築
Webブラウザが(13)のHTTPレスポンスを受信する。HTMLの場合は解析してDOMを構築し、CSSを適用して画面を描画する。AngularなどのSPAでは、JavaScriptがAPIからJSONなどを取得し、DOMを更新する場合もある。 - (15)ユーザーに要求結果を表示
(14)のHTMLをWebブラウザに表示。
まとめ
- Webシステムは、ブラウザ、Webサーバー、APサーバー、DBサーバーが連携して動き、クライアント側とサーバー側の処理を分けて考える。
- Webサーバーはリクエストを受け付ける入口、APサーバーはアプリケーション処理を担当する。
- HTTPリクエストは要求、HTTPレスポンスは応答であり、レスポンス本文をブラウザが解釈して画面として表示。
- Angularは主にクライアントサイドで画面表示や操作を制御。