プロになるためのWeb技術入門をまとめてみた
ネットで評判が良かったプロになるためのWeb技術入門 ――なぜ、あなたはWebシステムを開発できないのかを読みました。
非常にわかり易く内容も良かったので、内容をまとめます。
この記事を読めば一通りの内容は理解できるレベルになっていると思います。
■ 対象読者
1. これからWEBアプリケーション開発を始めてみたい人
2. WEB開発の経験はあるけど、何故動いてるのかよくわからない人
3. WEBアプリケーション開発のPMをしているが、技術がイマイチわかってない人
WEBアプリケーションを学ぶべき理由
1. Webアプリケーションシステムの進歩が早いから
2. Webアプリケーション開発に必要な知識が幅広いから
Webアプリケーション自体がここ１０年ほどの間に新しく広まったものであり、その開発手法自体も高速に進化しております。
よくある話ですが、数年前に流行った技術が数年後には枯れた技術になるケースもしばしばです。
進化の早いWEB業界では常にキャッチアップが必要です。
さらに、Webアプリケーションの開発に必要な知識は膨大です。何故ならWebアプリケーションはさまざまな技術を利用して成り立っているためです。
プログラミング技術はもちろん、ネットワーク、HTML、アプリケーションサーバー、OSの知識も必要になります。
このような幅広い知識を身につけることも重要になります。
1. WEBアプリケーションとは何か
1. 主な処理は、手元のPCではなくサーバー上で行われる
2. 画面が、HTMLで表現され、Webブラウザ上に表示されている
3. アプリケーションをPCへインストールする必要がない
■ 良く比較されるディスクトップアプリケーション※との比較
| ディスクトップアプリケーション | Webアプリケーション | |
|---|---|---|
| 処理の主体 | 手元のPC | サーバー |
| 画面の表示 | OS上で表示 | Webブラウザ上で表示 |
| インストール | 必要 | 不要 |
※ ディスクトップアプリケーションとはwordやexcelのようなもの
2. WEBアプリケーションはどのように発展したか
WWWの誕生と普及
インターネット普及の立役者www※1(WorldWideWeb)が誕生したことにより、インターネット上でのやりとりが普及した。
※1 Web 【ウェブ】 WWW / World Wide Web / ワールドワイドウェブ Webとは、インターネット上で標準的に用いられている文書の公開・閲覧システム。 文字や図表、画像、動画などを組み合わせた文書を配布することができる
Webを支える技術
WWWの普及に伴い、Webを支える技術が進化した。
Webサーバーとクライアント
WWWによるハイパーテキストの公開と閲覧は、具体的には「Webサーバー」と「Webクライアント」というソフトウェアで実現されています。
画像参考：いまさら聞けない「Webブラウザ」超入門
Webサーバーがネットワーク上で公開するリソースを保持し、クライアントの要求に従ってリソースを渡してあげる仕組みになっています。
クライアントからサーバーに対する要求をリクエストと呼び、サーバーからクライアントに対する応答をレスポンスと呼びます。
でも、なぜサーバーとクライアントを分けるのでしょうか？
理由は簡単でwwwのような不特定多数のクライアントからリクエストが来ることが想定される場合はWebサーバーのように一つのコンピューターに情報を集めておく方が管理が楽だからです。
URL
wwwの発明により、インターネット上には無限の情報が公開されるようになりました。
そこでURLが必要になります。クライアントがサーバーに対してどこどこにあるコンテンツが読みたいと指定する時にURLを利用します。
URLはリソースの保存先で一意に指定することが出来ます。
URLとはこのようなものです。
http://www.littleforest.jp/webtext/index.html
■ スキーム
スキームはリソースを取得するための方法を表します。Webアプリケーションの場合はほぼhttp(https)になります。
http
■ ホスト名
リソースが存在するホスト（コンピューター）名を表します。
ネットワークに接続されて他のコンピューターから要求を受け取り、処理した結果を返すようなコンピューターのことをホストと呼びます。
www.littleforest.jp
jp -> 日本の
littleforest -> littleforestという組織の
www -> wwwサーバーというコンピュター
■ パス名
ホスト名で指定されたコンピューター上のリソースの位置を示します。
webtext/index.html
-> webtextディレクトリのindex.htmlというファイル
■ オリジン(Origin)
オリジンとは、URLのスキーム・ホスト・ポートの３つの組み合わせの事をいいます。
http://www.example.com:80/index.htmlというURLを例にすると、
スキーム: http://
ホスト: www.exsample.com
ポート: 80 (ポート番号は省略可)
AとBという２つのオリジンがあったとして、この3つがすべて一致したときのみ「AとBは同じオリジンである」と言えます。
3. HTTPを知る
HTMLの送受信にはWebサイトを閲覧するときと同じようにHTTPが使われています。
HTTPはWEBアプリケーションの根幹になる技術です。
HTTPを知ることで、WEBアプリケーションの本質を知ることが出来ます。
HTTP通信の流れ
- クライアント側のPCでブラウザにURLを入力します。
- クライアント側のPCからWebサーバーに「HTTPリクエスト」を送信します。
- Webサーバーが、「HTTPリクエスト」に対応する「HTTPレスポンス」をクライアント側のPCに送信します。
- クライアント側のPCでWebページを表示します。
HTTPリクエスト
画像参考：TCP/IP - HTTP
■ リクエスト行
リクエスト行はメソッド、URI、HTTPバージョンの３つで成り立っています。
■ メソッド
リクエストの種類を表します。主に利用されるメソッドは４種類です。
GET : データの取得
POST : データの送信(主に新規作成)
PUT : データの送信(主に既存データの更新)
DELETE : データの削除
GETのパラメーターの受け渡しはクエリパラメータが基本。
POSTのパラメーターの受け渡しはメッセージボディに格納して送信するボディパラメータが基本。
■ URI
情報の場所を表すのがURIです。
■ HTTPバージョン
HTTPのバージョンを表します。
バージョンの違いによって、リクエストヘッダの種類が変わってきます。
■ メッセージヘッダ
リクエストの付加的な情報を表します。
詳細は割愛しますが、メッセージヘッダーには下記の内容が記載されているケースが多いです。
1. Accept
2. Accept-Language
3. User-Agent
4. Host
■ メッセージボディ
Webサーバにデータを送るために使用します。
例えば、Webページ上で入力欄がある場合そこに入力したテキスト情報をWebサーバに送るために使用。入力情報がなければ空白になります。
(おまけ)HTTPリクエストの際にクライアントで行われること
クライアントは一つのリクエストを送信し、レスポンスを受信する際に、下記の順で作業します。
- リクエストメッセージの構築
- リクエストメッセージの送信
- （レスポンス待機）
- レスポンスメッセージの受信
- レスポンスメッセージの解析
- レクライアントの目的を達成するために必要な処理
レスポンスの解析結果、再度リクエストする場合もあります。
例えば、画像ファイルにスタイルシートのリンクがいくつも含まれており、正しくHTMLレンダリングするためには５０回以上のリクエストを発行するなど。
HTTPレスポンス
画像参考：TCP/IP - HTTP
■ ステータス行
Webブラウザに、Webサーバでの処理結果を伝えます。 HTTPのバージョン、ステータスコード、説明文などの情報を含みます。
ステータスコードサンプル
1xx : information => リクエストの処理が継続していることを表す
2xx : Success => リクエストが成功したことを表す
3xx : Redirection => リクエストを完了させるには、さらに動作が必要なことを表す
4xx : Client Error => クライアント側に起因するエラーでリクエストが失敗したことを表す
5xx : Server Error => サーバーに起因するエラーでリクエストが失敗したことを表す
■ メッセージヘッダ
WebブラウザにWebサーバの情報を示します。
具体的に、サーバの種類 返信するデータのタイプ、データの圧縮方法などの情報を含みます。
■ メッセージボディ
HTML文書、画像ファイル、動画ファイルなどのデータを格納するために使用します。
(おまけ)HTTPレスポンスの際にサーバーで行われること
クライアントからリクエストを受けたサーバーは下記の順で作業します。
- （リクエストの待機）
- リクエストメッセージの受信
- リクエストメッセージの解析
- 適切なアプリケーションプログラムへの処理の展開
- アプリケーションプログラムから結果を取得
- レスポンスメッセージの構築
- レスポンスメッセージの送信
4. CGIからWEBアプリケーションへ
WEBアプリケーションの特徴を記載します。
ステートフルなプロトコルとステートレスなプロトコル
HTTPはプロトコルがステートレスであることが特徴です。
ステートレスとは状態を保持しないと言う意味で、HTTPではリクエスト/レスポンスの一往復のやりとりが完結した処理とみなされます。
逆にステートフルとは状態を保持しておき、次の処理に反映させるような方式になります。
大量のユーザーがアクセスすることが想定される現代のWEBサービスでは多くの処理を素早く処理できるステートレス方式が採用されるケースが多いです。（状態を保持するステートフルでは多くの処理を処理するには負担が大きすぎるため現代のWEBには不向き）
しかし、Webが進化するにあたってステートレスでは困る状況が増えてきました。
例えば、ショッピングサイトでは「商品を選ぶ」「商品を買い物カゴに入れる」などといった動作はWebサーバーから見るとWebブラウザからの異なる動作（HTTPリクエスト）になります。
そのために、商品を買い物カゴに入れるという動作をしたとしても「商品を買い物カゴに入れた」という状態を保持できないため、次の動作で商品の買い物カゴを確認したとしても商品が入っていないということになってしまいます。
しかし、実際のショッピングサイトでは、買い物カゴに入れた商品を確認したり、商品を購入できたりします。
これはHTTPを補完する別の仕組みとして、以前の状態を踏まえた上で次の動作をするといった、状態を保持し管理する仕組み、Cookieやセッションが導入されているからです。
Cookieを利用して状態を保持する
CookieとはHTTPの仕様を拡張してWEBアプリケーションとWEBブラウザの間で情報を交換できるようにしたものです。
Cookieの送信方法ではメッセージヘッダー（HTTPヘッダ）に格納して送信されます。
例）
画像参考：HTTP headers | Cookie
WEBサーバーからCookieを受け取った、Webブラウザは次回同じWebサーバーにアクセスする際、受け取ったCookieをそのままHTTPリクエストヘッダーに入れて送ります。
WEbアプリケーション側ではリクエストヘッダーに入っているCookieを調べることで、アクセスしてきた相手がどのような相手なのかを知ることが出来ます。
一方で、例えCookieを受け取った後でも、Cookie受け取ったサーバーと異なるWebサーバーに対してはCookieを送りません。この仕組みによって、意図しない情報が他のWebサーバーに送られてしまうことを防ぐことが出来ます。
Cookieは基本的にたったこれだけの簡単な仕組みです。
安全に状態を保持する技術-セッション-
Cookieを利用することで、Webブラウザに状態を持たせることができるようになります。
しかし、セキュリティ上の問題があります。Cookieを利用した情報のやりとりは、HTTPリクエスト（ヘッダー）やレスポンスヘッダを利用して行われます。
より安全に多くの情報を保持するための方法としてセッションと呼ばれる仕組みが開発されました。
クライアント単位に発行されるキーとなるのが、セッションIDです。サーバーサイドでは、クライアントから発信されたセッションIDをキーにして、セッション情報にアクセスできます。
これによって、セッションでは「データがユーザーに改ざん／削除されてしまう」「データを盗聴されやすい」という、クッキーの問題点を解消しています。
■ Cookieとセッションの処理フローまとめ
画像参考：ASP.NETの状態管理
5. Webアプリケーションの構成要素
Webアプリケーションの構成について、もう少し大きな観点から説明していきます。
データーベースサーバー
アプリケーションが高度化してくると、大量のデータを扱うようになるのでデータベースが必要になってきます。
データベースとはコンピューター上の大量のデータを蓄積し、効率よく検索できるようにしたソフトウェアのことを言います。
データベースの実現に特化したソフトウェアをデータベース管理システム（DBMS）と呼びます。
データベース管理システムを利用すれば、コンピューター上にデータベースの構築し、大量の情報を記憶してさまざまな条件で高速に検索したり計算することが可能になります。
| 正式名称 | 意味 | |
|---|---|---|
| DB | Database | コンピューター上で扱う情報の集合のこと |
| DBMS | Database Management System | データベース管理システム。データベースを構築し、扱うためのソフトウェア |
| RDBMS | Relational Database Management Sysytem | リレーショナルデータベースを扱うDBMS |
データーバーに対する操作
データベースに対する操作はそれぞれの頭文字を取りCRUDと呼ばれます。
このような処理（命令）をデータベースに効率よく伝える言語としてSQLがあります。
SQLの説明は長くなるので割愛します。
Create : 作成 => 新しい情報を登録する
Read : 読み取り => 情報を読み取る
Update : 更新 => 情報を更新する
Delete : 削除 => 情報を削除する
データベースサーバーの分離
一般的にWebサーバーを動作させるコンピューターとデータベースを動作させるコンピューターを別々に用意し、各プロセスをそれぞれのコンピューター上で動かすようにします。
このようにすることで、各コンピューターの仕事が分散されて負荷が下がります。
WEBシステムの三層構造
Webアプリケーションの主役となる３つの構成要素、Webサーバー、アプリケーションサーバー、データベースサーバーの典型的な構成例を記載します。
■ 最小構成のWebシステム構成
最も簡単な構成のWebシステムです。サーバーサイドは１台のコンピューターの中でAPサーバーとDBサーバーのみを稼働させます。Webサーバーを省略して、APサーバーが提供するWebサーバーの機能を利用します。
■ 最小構成にWEBサーバーを追加するシステム構成
最小構成にWEBサーバーを省略せずにAppacheなどを利用するケースです。
■ 一般的なシステム構成
それぞれのサーバーを別々のノード上に配置します。このようにすることで、それぞれのコンピューターの持つリソースを各サーバーへ最大限振り分けることが可能になります。利用者の多い、中規模以上のWebシステムで採用されるケースが多いです。
6. WEBアプリケーションを効率よく開発するための仕組み
WEBアプリケーションのアーキテクチャ
WEBアプリケーションの構築をするときに必要な考え方にロジックとデザインの分離があります。
ロジックとはユーザーの入力された情報が正しいか判定する処理などの部分がロジックになります。
一方で、デザインとはユーザーが目にする画面表示部分を意味します。
ロジックとデザインでは求めるスキルは違うので、それぞれプログラマとデザイナーで分業したほうが効率が上がります。
大規模なWebアプリケーション開発になると、その全体構造を最初に考えなければ品質の良いWebアプリケーションを開発することができません。
設計スタイルとその設計に基づく全体構造をアーキテクチャと言います。
有名なWebアプリケーションアーキテクチャにMVCモデルが存在します。
MVCモデルでは「モデル」「ビュー」「コントローラー」の３つの役割に分けて作ります。
入力はコントローラーに、処理はモデルに、出力はビューに相当します。
!
1: WEBブラウザからリクエスト送信
2: リクエストからパラメーターを取得し、必要であればセッション情報から情報の取り出しを行い、入力情報を処理するモデルに引き渡す
3: 受け取ったパラメーターをもとに処理を行い、その結果をコントローラーに返却する
4: モデルから受け取ったステータスをもとに、表示すべき画面を選択し、その画面を表示するためのビューを呼び出す
5: ビューはもでを参照して表示すべき情報を取り出す
6: HTML出力して、HTTPレスポンスとしてWebブラウザに返却する
フレームワークによるアーキテクチャの実現
アーキテクチャの知見を簡単に実現できるようにするための手法としてフレームワークがあります。
フレームワークという言葉の本来の意味は「枠組み」や「構造」という意味です。
有名なフレームワークで言うとRubyOnRailsなどがあります。
■ フレームワーク利用のメリット
1. 設計,開発工数の削減
2. 品質の向上
3. テスト工数の削減
■ フレームワーク利用のデメリット
1. 学習コストの増大
2. 設計のおける自由度の低下
3. 長期的な技術力の低下
個人的に考えるフレームワークの最大のデメリットは長期的な技術力の低下と考えます。
フレームワークは非常に高い技術と長い経験に基づく知見を集約した結果であり、うまく利用することで様々なメリットが得られます。
ただ、大抵のフレームワークは簡単に使用できるように内部をブラックボックス化してまうため、その裏側でどのようなことが行われているのかを知ることができなくなってしまいます。
自分はRailsエンジニアなのですが、確かにRailsは優秀なフレームワークですが、内部がブラックボックスなのでRailsだけ触っているエンジニアはあるポイントで技術力の向上が見込めなくなると考えています。
レイヤーパターンによるデータアクセス層の分離
Webアプリケーションのようなさまざまな技術を組み合わせて作る複雑なシステムでは、MVCモデルと合わせてレイヤーと呼ばれるアーキテクチャが利用されます。
レイヤーパターンはシステムを断層化し、上位レイヤが下位レイヤの提供する機能を利用することで、各レイヤの作りを単純化しています。
現在では下記のようなレイヤの分け方が一般的になっています。
-----------------------
プレゼンテーション層
-----------------------
↓
-----------------------
ビジネスロジック層
-----------------------
↓
-----------------------
データアクセス層
-----------------------
■ プレゼンテーション層
システムと利用者のインターフェースを担当するレイヤ。
Webブラウザからユーザーの入力を受けとり下位レイヤであるビジネスロジック層へ渡し、その処理結果を再びWebブラウザへ表示させたり、画面遷移させます。
■ ビジネスロジック層
アプリケーションが実現すべき固有の処理を実行するためのレイヤ。
ビジネスロジックは、ユーザーが入力した情報をプレゼンテーション層から受け取り、必要に応じてデータアクセス層を通じてDBを利用し、処理を実行します。
処理結果は再びプレゼンテーション層に返却します。
■ データアクセス層
データアクセス層は、ビジネスロジック層とデータベースの仲立ちを行うためのレイヤです。
データベースへの細かなアクセス手順を意識せずとも利用できるようにするのがデータアクセス層の役目になります。
!
7. セキュリティを確保するための仕組み
Webアプリケーションを開発する上でセキュリティを確保することは非常に大事です。
Webアプリケーションにおいて守るべき情報セキュリティは下記の３つです。
1. 第三者への流失を避ける（機密性）
2. 第三者への情報の改竄を防ぐ（完全性）
3. 適切な権限を持った人間が適切な情報を利用できる（可用性）
代表的なWebアプリケーションの攻撃手法一覧
1. SQLインジェクション
2. クロスサイトスクリプティング（XSS)
3. セッションハイジャック
4. クロスサイトリクエストフォージェリ（CSRF)
セキュリティについてはこちらの記事にまとめがあるので、参照ください。
https://qiita.com/Marusoccer/items/cdc6124570ed1f5733bd
まとめ
WEB開発する上での重要ポイントがまとまっており読みやすかったです。
比較的初心者向きですので、WEBエンジニア数年程度の人に向いているのではないかと思います。
参考