目的

この記事では、WebシステムをAngularを用いて開発するにあたって、最低限必要なWebアプリの前提知識について要説する。

Webシステムとは

Webシステム（Webアプリ）は、Webブラウザ上で利用できるサービスやそのシステムの総称を指し、次項で示す クライアントサイドとサーバーサイド間をHTTP通信（通信プロトコル）を用いてやり取りする。

このやり取りについては、次項で示すHTTPリクエスト（ユーザーの要求情報）、HTTPレスポンス（サーバーの応答結果）のデータ構造で送信され、クライアント/サーバー間のインターフェースとして重要な役割を持つ。

※ Webブラウザではなく、ユーザー端末用のソフトウェアをインストールしてサーバー間通信を行うクライアントサーバーシステム（C/Sシステム）と混同注意。

また、Webシステムには、以下のメリット、デメリットがあるが、日々進化し続けるフレームワークがデメリットを考慮した方針で作られているため、製造側（プログラマー）は、あまり意識せずに開発することができる。

• ユーザー側のメリット
  通信環境とWebブラウザのみで利用でき、特別なソフトウェアのインストールが不要。
  PC、タブレット、スマートフォンなど幅広い端末で同時に利用できる。
  バージョンアップの際、ユーザー側の負担が少ない。
  ブラウザの推奨バージョンが上がった場合は、ブラウザの最新化が必要。

• 運用側のメリット
  検索エンジンからダイレクトに新規ユーザーのアクセスを受け入れられる。
  WebシステムのURLやQRコードのみのシンプルな広告を出せ、SNSでも拡散されやすい。
  ユーザー端末に特別なソフトウェアが不要なため、初期設定やバージョンアップ時のプログラム配布コストがない。

• ユーザー側のデメリット
  通信ができない環境では、Webシステムを全く利用できない。
  通信速度が回線やユーザー端末の性能に左右され、システム利用に大きな支障をきたす場合がある。

• 運用側のデメリット
  外部からのハッキングやデータ改ざん、不正アクセスなどあらゆるセキュリティ攻撃を想定し、万全なセキュリティ対策を徹底しなければならない。
  ユーザーの同時アクセスにより、サーバーに負荷が集中するため、アクセス数を明確に見越したサーバー設計（マシン構成や負荷分散）が必要。
  Webブラウザの仕様制限でWebシステムの柔軟な開発ができない。
  WebブラウザやOS依存の個別対応が必要。
  ユーザー端末に内蔵されているカメラ機能、GPS機能、プッシュ通知機能などのネイティブ機能は、セキュリティ面からできることが限られている。
  開発方針や開発言語の技術進歩が速いため、学習コストが高く、有識者の確保が困難。

クライアントサイドとは

クライアントサイドとは、ユーザー（クライアント）によって実行される操作やユーザー端末上で実行されるWebブラウザの処理などクライアント側で起こり得る事象全般の総称を指し、フロントサイドとも呼ばれ、単にクライアントともいう。

クライアントサイドの処理は、次項で示すクライアントサイドのHTTPレスポンスで以下 \(3\) つのクライアントサイドプログラムを受信し、Webブラウザ上で実行される。

※ 実行タイミングは、次項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ブラウザ上で動くプログラム言語で、全てのブラウザに実行環境が搭載されており、キーボードやマウス操作などユーザーの操作イベントに応じた画面制御や動的処理を組むことができる。
  また、JavaScriptは、ほぼ全てのWebサイトに導入されており、現時点で代わりとなる言語がないため、Web業界において、最も利用率が高い言語でもある。
  なお、システム開発時は、JavaScriptで一から書くのではなく開発効率を上げるため、フレームワークを用いた開発が主流で以下の代表的なフレームワークがある。
  

  • Angular（アンギュラー） TypeScript（JavaScriptの上位互換）を使用する。
  • React（リアクト） JavaScriptを使用する。
  • Vue.js（ビュージェイエス） JavaScript、TypeScriptを使用する。

サーバーサイドとは

サーバーサイドとは、クライアントサイドから送信される全てのユーザー要求を受け付け、応答を返すWebシステム中枢部の総称を指し、バックサイドとも呼ばれ、単にサーバーともいう。

サーバーサイドの実体は、クラウドサービスやデータセンターにより一括管理されている高機能の物理サーバーで、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）インタプリタ型言語
  プログラムコードの命令単位に機械語へ逐次変換しながら実行するプログラム言語で手軽に動作確認でき、開発（デバッグ）しやすいがコンパイラ型言語（＊3）と比べると処理速度が遅い。

• （＊2）オブジェクト指向
  応用情報技術 - 基礎覚書き：プログラム構造・言語 > プログラム言語の変遷を参考。

• （＊3）コンパイラ型言語
  関連するプログラムコードを全て機械語に変換してから実行するプログラム言語でインタプリタ型言語（＊1）と比べ処理速度が速いが、動作確認毎に全て機械語に変換するため、デバッグにやや時間がかかり、プログラム改修時のデプロイも容易にできない。

HTTPリクエスト

HTTPリクエストは、要求情報以外にもクライアント端末の情報やサーバーサイドからのレスポンスデータに関する型の指定など複数の項目があり、下記 リクエストライン、リクエストヘッダー、リクエストボディの \(3\) 構成で記述される。

※ データ構造は、下記並びで空行を含む。 リクエストライン、リクエストヘッダー、空行（CR + LF）、リクエストボディ

• リクエストライン
  下記の \(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
    

• リクエストヘッダー
  下記ヘッダーに大別され、項目名と内容をコロンで区切ったデータフォーマットで、[項目名]:[内容]を縦に列挙して記述される。

  • ジェネラルヘッダー
    Date : HTTPリクエストの作成日時。
    Pragma : キャッシュ許容などの通信オプション。
    Cache-Control : キャッシュ制御に必要な指示や情報。
    Connection : TCPコネクションを接続状態を指定する通信オプション。
    Transfer-Encoding : リクエストボディのエンコーディング方式。
    Via : クライアント/サーバー間の転送経路。
    など

  • リクエストヘッダー（詳細部）
    Authorization : ユーザーの認証情報。（下記 HTTPレスポンスのWWW-Authenticateの応答）
    From : ユーザーのメールアドレス。
    Referer : 前回ページを取得した時のページURL。
    User-Agent : Webブラウザの固有情報。
    Accept : Webブラウザが受入可能なMIME（メディアタイプ）。
    Accept-Charset : Webブラウザが受入可能な文字セット。
    Accept-Encoding : Webブラウザが受入可能なエンコーディング方法。
    Accept-Language : Webブラウザが受入可能な言語コード。
    など

  • エンティティヘッダー
    Content-Encoding : リクエストボディのエンコーディング方式。
    Content-Language : リクエストボディの言語コード。
    Content-Length : リクエストボディのサイズ（単位 : Byte）。
    Content-Type : リクエストボディのメディアタイプ。
    Expires : リクエストボディの有効期限。
    Last-Modified : リクエストボディの最終更新日時。
    

  • 例 : 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=s-hama@sigma-se.jp&name=hama&comment=example
    

HTTPレスポンス

HTTPレスポンスには、HTTPリクエストに対するサーバーの応答結果が、下記 リクエストライン、リクエストヘッダー、リクエストボディの \(3\) 構成で記述される。

※ データ構造は、下記並びで空行を含む。 ステータスライン、レスポンスヘッダー、空行（CR + LF）、レスポンスボディ

• ステータスライン
  下記の \(3\) 項目を半角スペース区切りで並べたデータフォーマットで、[プロトコル] [ステータスコード] [テキストフレーズ]となる \(1\) 行のデータで記述される。

  • プロトコル
    HTTPレスポンスのプロトコル「HTTP」とそのバージョンを指定する。

  • ステータスコード
    リクエストに対するサーバーレスポンスの状態を表す数字3桁のコードで、下記5つに大別される。
    

    • \(100\)番台 : サーバー処理継続状態などの情報レスポンス
    • \(200\)番台 : サーバー処理が成功した場合のレスポンス
    • \(300\)番台 : リクエスト応答の必要な追加情報や応答の状態を示すレスポンス
    • \(400\)番台 : クライアントサイドのエラーレスポンス
    • \(500\)番台 : サーバーサイドのエラーレスポンス ※ 詳細なエラーコードについては、下記を参考。
      [Qiita] HTTPステータスコード 完全に理解した

  • テキストフレーズ
    ステータスコードの概要が記述される。 ステータスコードが \(200\) である場合の\(OK\)や \(404\) である場合の\(Not Found\)など。

  • 例 : ステータスコードが \(200\) のステータスライン

    HTTP/1.1 200 OK
    

  • 例 : ステータスコードが \(404\) のステータスライン

    HTTP/1.1 404 Not Found
    

• レスポンスヘッダー
  リクエストヘッダーと同様に下記ヘッダーに大別され、項目名と内容をコロンで区切ったデータフォーマットで、[項目名]:[内容]を縦に列挙し記述される。
  ※ 上記のプロトコルによって定義項目が増減し、利用頻度も低いため、代表的な項目のみ触れる。

  • ジェネラルヘッダー
    上記 HTTPリクエストの共通メインヘッダーであるため、記載内容はほぼ同じ。

    • Date : HTTPレスポンスの作成日時。
    • Pragma : キャッシュ許容などの通信オプション。
    • Cache-Control : キャッシュ制御に必要な指示や情報。
    • Connection : TCPコネクションを接続状態を指定する通信オプション。
    • Transfer-Encoding : レスポンスボディのエンコーディング方式。
    • Via : クライアント/サーバー間の転送経路。
    • など

  • レスポンスヘッダー（詳細部）
    レスポンスの追加情報やサーバーサイド固有の情報を付与するためのヘッダー。

    • Location : リダイレクト先の絶対URL。
    • Server : Webサーバーのサーバー名やバージョンなどサーバー固有の情報。
    • WWW-Authenticate : Webサーバーがクライアントに要求するユーザーの認証情報。
    • Age : リソース・コンテンツ生成後の経過時間。
      • （キャッシュしたデータが最新であるかどうかの判断に使用する。）
    • Proxy-Authenticate : プロキシサーバーがWebブラウザに要求するユーザーの認証情報。
    • Retry-After : Webサーバー側の停止によるリクエスト再試行までの待機時間を指定する。
    • Warning : ステータスコードの付加情報。
    • など

  • エンティティヘッダー
    上記の HTTPリクエストの共通サブヘッダーであるため、記載内容はほぼ同じ。

    • Content-Encoding : レスポンスボディのエンコーディング方式。
    • Content-Language : レスポンスボディの言語コード。
    • Content-Length : レスポンスボディのサイズ（単位 : Byte）。
    • Content-Type : レスポンスボディのメディアタイプ。
    • Expires : レスポンスボディの有効期限。
    • 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で記述される。

  • 例 : 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 Tech Blog" />
      <meta property="og:description" content="Engineer Tech Blog" />
      <meta property="og:image" content="/static/macuos/img/sigma-se2.jpg" />
      <meta property="author" content="sigma-se Tech Blog" />
      <!-- 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サーバーに構築されているソフトウェア（Nignx、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（レスポンスボディ）を生成する。
• （13）クライアントサイドにHTTPレスポンスを返却
  レスポンスヘッダーと（12）の レスポンスボディをクライアントサイドプログラムに返却する。
  （6）レスポンスボディのHTMLには、JavaScriptとCSSが埋込まれた状態で送信される。
• （14）HTTPレスポンスの受信とHTML成型
  上記（6）でWebサーバーから返却されたクライアントサイドプログラムが（13）のHTTPレスポンスを読み込み、画面表示に必要なページ情報（HTML）を成型する。
• （15）ユーザーに要求結果をアウトプット
  （14）のHTMLをWebブラウザに表示する。