本書について
〇レベル
★★基礎レベル
（前提知識を要さず読める基礎レベルの本）
〇ジャンル
Web Service
〇想定読者
・これまでWebServiceを作ったことがない人
・Web周辺の技術について体系的に理解したい人
本書はWebServiceビギナー向けに、Webの周辺技術を実際に触って確かめる入門本となっております。10年前の本なので紹介されているアプリやフレームワークは古いですが、現代でも変わらないWeb技術の根幹を学習するのに役立つと思います。
それでは、各章ごとに私なりの理解を踏まえて以下に要約していきます。
1章
本章では、デスクトップアプリとWebアプリの差異が記されています。
2章
本章では、WorldWideWeb（以下、Web）そのものの説明とWebを支える要素技術、CGIの台頭などが記されています。
まず、Webに関して。Internetと同様に語られるWebですがこれらは微妙に違います。
Internetは、Network of Networksとも言われるように一つ一つのNWの集合体であり、コンピュータを相互接続する網を表しています。
それに対してWebは、HTML・URL・HTTPの３つの技術から成る情報伝達の仕組みのことを指します。この３つの技術はWebを理解する上でとても大事な役割を担っているのでそれぞれ簡単に役割を記します。
HTMLは、HyperTextMarkupLannguageの略であり、Webサイトを構成する骨組みのようなものとなっております。お使いのブラウザがGoogle ChromeであればCtrl ＋Uでソースコードを閲覧することができるのでそちらで確認ください。そこに書かれているタグ区切りの文字列こそがHTMLで書かれたものとなり、これがWebサイトの中身（コンテンツ）となります。
URLは、UniformResourceLocatorの略であり、簡単に言うとWebサイトの住所を表すものとなっております（似たものにIPアドレスがありますが、そちらは郵便番号のようなものになります）。
例えば、Qiitaの私の記事のURLだと、以下のようになります。
https://qiita.com/revvve44/items/2554526cbf403e3a66ae
ここでhttps:の部分がスキームと言って通信するプロトコルを指定する箇所となっており、qiita.comの部分がホスト名と言ってWebサイトの名前を決めるものとなっております。最後に、/items/2554526cbf403e3a66aeの部分がパス名と言ってWebサイト内のHTMLページの位置を表すものとなっております（一つのWebサイトでも複数のページで構成されているのでパスという概念が必要なのです）
HTTPは、HyperTextTransferProtocolの略であり、Web内を通信するプロトコル（様式のようなもの）となります。Versionが1.0と1.1のものがあり現在の主流はVer1.1となります。また、メソッドと言われるものが定義されているのですが、ほとんどの場合使われるのはGETメソッドとなります。参考にHTTPのメソッド一覧を掲載しておきます。
さて、InternetとWebの技術によって、全世界をつなぐ物理的な通信網と通信の中身、住所、様式が決まりました。あと実際に通信をする上で足りない役者は通信をする主体ですね。人間界であれば通信（おしゃべり）する主体は人間ですが、ITの世界で通信する主体といえば人間ではなくてコンピュータとなります。じゃあ、Internetの任意の点に2台のコンピュータを置いてやれば通信するのかというとそういうわけでもなくて、最後に役割を決めてあげる必要があるんですよね。
役割とは何かと言うとサーバとクライアントのことです。人間にも男性と女性みたいな概念があるように、コンピュータの世界にも役割の違いがあってサーバ側がコンテンツを提供する側でクライアント側がコンテンツを享受する側となります。どちらもコンピュータであることは間違いないのですが、サーバとクライアントではOSとソフトウェアが違います。
サーバ側のOSはLinuxなどが有名ですね。また、Webサーバ用のソフトウェアとしてApacheやNginx（engine Xと発音します）が必要です。対してクライアント側のOSはおなじみのWindowsやMac、ソフトウェアというのがブラウザに当たり、Google ChromeやFireFox、MicrosoftEdgeなどがそれに該当します。
さて。
サーバとクライアントの２つの役者を登場させてやっとWebでの通信が成立します。そして、2台のコンピュータをサーバとクライアントに分けて通信させるのがもっとも原始的なWeb Serviceの構成となります（だんだん複雑化していきます）
では、なぜWebサーバとクライアントの通信は複雑化していくのでしょうか。原因となる一つの流れが静的Webサイトから動的Webサイトへの変化です。静的と動的というのは、簡単に言うとWebサイトに変化がないのが静的なサービスで、変化があるのが動的なサービスとなります。つまり、いつ見ても変化しないWebサイトが静的Webサイト、見る時によって状態が変化するWebサイトが動的Webサイトということですね（ニュースサイトや証券サイトなどが分かりやすく、要はよく更新されるサイトです）
こうした動的Ｗebサイトを生成するもっとも原始的な技術がCGIと呼ばれる技術です。
CGIとは、CommonGatewayInterfaceの略であり、PerlやPHPで実装されるプログラムのインターフェースとなります。
CGIやその他の応用的なWeb技術の紹介はここでは割愛しますが、かくしてWebは発展していきました。
3章
本章では、HTTPの詳細、クエリ文字列、パーセントエンコーディング。そして、TCP/IPについて記されています。
2章でWebが何で構成されていて、どういう役割分担でWebServiceが成り立っているかを概説しました。しかし、Internetの世界は広大であり2章の技術だけでは実際にInternet上で通信させることはできません。なぜかというと、Internet上に膨大に存在するWebサーバをWebクライアントが見つけられないからです。
あれ？でも、おかしいですよね。
さっきURLが住所の役割を担うと言いました。では、URLさえあればWebクライアントは目的のWebサーバまで辿りつけるはずではないでしょうか。しかし、実際には辿り着きません。なぜなら、URLはあくまでWeb上で目的のHTMLファイルを特定するための住所であるからです。実際に通信する物理的なコンピュータを特定するにはまた別の技術が必要なわけですね。それがTCP/IPとなります。
では、TCP/IPとは何かという話に移ります。本書でも例に出されていますが簡単に言うと郵便に近い話になります。
例えば、東京から大阪に郵便物を配達する時、様々なプロセスを介して郵便物は送り主から受取先へと配達されると思います。具体的に見ていきましょう。
まず、送り主と受取先の住所を記載しますよね。これがない郵便物は辿り着きません。これが通信の世界ではIPアドレスというものになります。IPアドレスというのは32bit(4byte)で記述されたホスト識別番号となります。例えば、GoogleのDNSサーバですと8.8.8.8であり、このように0~255(8bit)の4桁で構成される番号となっております。
このIPアドレスを用いて実際に通信先を一意に特定するのですが、それではTCPというのはなんでしょう？これはIPより1層上の通信プロトコルです。
1層上？なんのことでしょう。
これはOSI参照モデル(OpenSystemsInterconnection)の中での1層上ということになります。OSI参照モデルについて説明しだすとキリがないので以下のサイトをご参考ください。
では、Webの住所であるURLとInternetの郵便番号であるIPアドレスはまったく関係がないのでしょうか？
そんなことはありません。人間界での住所と郵便番号は日本郵便のデータベースを使えば変換できるように、あるいは、住所と電話番号はタウンページを使えば変換できるように、URL（正式に言うとドメイン）とIPアドレスも変換可能なのです。
そして、変換時に用いるものがDNSと呼ばれるものになります。
DNSとは、DomainNameSystemの略であり、ドメイン名とIPアドレスを変換する辞書のようなシステムです。
説明だけでは分かりにくいと思うので実際にWebに存在するもので確認してみましょう。まず、お使いのPCからターミナルを開いてください。WindowsだったらコマンドプロンプトかPowerShell、どちらでも実行可能です。そこで以下のコマンドをたたいてみましょう。
nslookup google.com
nslookupというのはドメイン名からIPアドレスを検索するコマンドですね。今回ドメイン名としてお馴染みのGoogle検索を用いました。すると以下のように返ってくるはずです
サーバー: UnKnown
Address: 192.168.2.1
権限のない回答:
名前: google.com
Addresses: 2404:6800:400a:80b::200e
172.217.161.206
この172.217.161.206というのがgoogle.comのIPアドレスになります。ためしにブラウザで172.217.161.206と打ってもらうとgoogle.comに遷移するはずです。
DNSの詳しい説明はここでは実施しませんが、WebベンダであるCloudflare社の解説記事が分かりやすかったので、以下に掲載しておきます。（だが、英語だ）
4章
本章では、WebサーバとWebクライアントの通信の仕方について記されています。
これまでの章でWebServieceはWebサーバとWebクライアント間でやりとりされるものであって、その間の通信プロトコルはHTTPを使用するということが分かったかと思います。
しかし、HTTPだけでWebサーバとWebクライアントの通信をさせるにはまだ不十分です。なぜなら、HTTPはステートレスなプロトコルだからです。Stateというのは直訳すると状態であり、文字通り通信の状態を保持するかどうかという意味を表します。
ここで、通信の状態とは一体なんでしょうか？
まずは通信の状態を持つステートフルな状態としてハンバーガーショップの店員とお客さんの会話で考えてみましょう。Webの世界では店員がWebサーバでお客さんがWebクライアントとなります（Clientの直訳がお客さんなので想像がつくかもしれませんね）以下に例を示します。
店員：いらっしゃいませ。ご注文を承ります。
お客さん：ハンバーガー1個とコーラのMサイズが１つ。
店員：ハンバーガー1個とコーラのMサイズが1つですね？お会計は300円になります。
お客さん：すいません。追加でポテトのLサイズもください。
店員：承りました。ハンバーガー1個とコーラのMサイズが1つ、ポテトのLサイズが1つですね。それではお会計変わりまして、530円になります。
といった感じに店員はお客さんの注文状況を脳内に保持しています。人間はコンピュータと違って近い過去の情報を脳内に保持しているので基本的にステートフルな会話をします。初対面の人と会話をすると名前を覚えるので次回会ったときに再度名前を尋ねることはないですよね。もし、あなたが人の名前を覚えなくて再度名前を尋ねるようならあなたはステートレスなプロトコルを利用しているのかもしれません。
さて、人間の会話は基本的にステートフルですが、上記の会話がもしステートレスに行われたとすれば以下のようになります。
店員：いらっしゃいませ。ご注文を承ります。
お客さん：ハンバーガー1個とコーラのMサイズが１つ。
店員：ハンバーガー1個とコーラのMサイズが1つですね？お会計は300円になります。
お客さん：すいません。追加でポテトのLサイズもください。
店員：ポテトのLサイズが1つですね？お会計は230円になります。
こんな感じになります。つまり、お客さんが同じであったとしても（同じクライアントからの通信だとしても）Webサーバ側はそれらを覚えていないのです。なので、たとえ同じお客さんであっても一から注文処理するのがステートレスな通信となります。しかし、このままではいろいろと問題がありそうですね。静的なWebサイト（Webサイトの内容が全く変わらないもの）なら問題ないかもしれませんが動的なWebサイトの場合そうはいきません。例えばショッピングサイトを想像してみてください。なにかを買い物カゴに入れたとして次のページに遷移した時、買い物カゴの中身が空っぽになっていたら困りますよね。しかし、HTTPのステートレスな通信だけでは通信の状態を維持できません。
そこで登場するのがHTTPCookieとなります。🍪
クッキー？何それ、おいしいの？といった感じですがおいしくはありません。HTTPCookieというのはHTTPを疑似的にステートフルに見せられる技術でありWebクライアントに通信状態を保持させるものになります。
先の会話でいえばこうなります。
店員：いらっしゃいませ。ご注文を承ります。
お客さん：ハンバーガー1個とコーラのMサイズが１つ。
店員：ハンバーガー1個とコーラのMサイズが1つですね？お会計は300円になります。
お客さん：すいません。先ほどハンバーガー1個とコーラのMサイズを1つ注文した者ですが、追加でポテトのLサイズもください。
店員：ハンバーガー1個とコーラのMサイズを1つ、ポテトのLサイズが1つですね？お会計は530円になります。
このようにお客さん側（Webクライアント側）が通信状態を教えてあげることで疑似的に通信全体の状態を保っています。ショッピングサイトの例でいうとUser名が○○でPasswordが××で買い物状態がリンゴ1個とみかん2個みたいなのをクライアント側がサーバ側に通信の度に教えてあげるようになります。しかし、これだけでは問題がありそうです。
問題は大きく2点あって、クライアント側の負荷の問題とセキュリティの問題です。
まずはクライアント側の負荷の問題ですが、先ほどWebサーバとWebクライアントは人間界でいうと男性と女性くらい別のものだと言いました。つまり、クライアント側ばかりに負荷がいく状態というのは人間界でいうと女性ばかりに負荷がいく状態に近いです。
例えば、共働きの夫婦がいるとします。夫は日中フルタイムで仕事をするだけですが、妻は日中フルタイムで仕事をした上に帰宅前に夕飯の買い物に出かけ夫と子どもの分の晩ご飯を作り本日分の洗濯と家事をこなし、子どもの明日のお弁当を作った上でお風呂を湧かす。みたいな感じです。（少々過激ですが）
現代社会でこんな関係では離婚必至でしょう。
「なんで私ばっかりがこんなに辛い思いをしないといけないのよ！」
と言って里帰りされることが容易に想像できます。
次にセキュリティの問題です。
クライアント側が都度UserやPasswordをサーバに送信するのはまずいというのは検討がつくでしょう。そう。盗聴されれば個人情報が一発で全てばれるということですね。個人情報はなるべくWebのやり取りでは最小限にした方が良いです。
そこで考案されたのがセッションという考え方です。
セッションというのは、先ほどのハンバーガーショップの会話でいうと番号札を配るという考え方に近いです。では、ステートレスな会話（HTTP通信）に番号札を配る（HTTPCookieにSessionIDを持たせる）やり取りを見ていきましょう。
店員：いらっしゃいませ。ご注文を承ります。
お客さん：ハンバーガー1個とコーラのMサイズが１つ。
店員：ハンバーガー1個とコーラのMサイズが1つですね？お会計は300円になります。番号札3番でお待ちください。
お客さん：すいません。番号札3番の者ですが、追加でポテトのLサイズもください。
店員：番号札3番の方ですね？では、お会計変わりまして530円になります。
この番号札の考え方がセッションの考え方であり、実際に配る番号札が通信の世界ではSessionIDとなります。サーバから配布されたSessionIDをクライアント側で保持し（キャッシュする）、通信の都度サーバに教えてあげるというわけですね。HTTPCookieなのでSessionIDを渡すのはクライアント側の役割になります。
しかし、セッションを導入することでクライアント側の負荷は一気に下がりました。なぜならUser名やPasswordや注文状況などのデータはサーバ側（データベース）に保持させてクライアント側はとりあえずSessionIDだけ保持していれば良いことになるからですね。これこそ共同作業であって介の字張りです。
このような役割分担の精神があって初めてWebの通信は成立するのですね。
5章
本章では、Webアプリの構成について記されています。
2章でWebアプリの最小限の構成は、WebサーバとWebクライアントの2台の構成であると書きました。このWebサーバの方をサーバサイド、Webクライアントの方をクライアントサイドと呼びます。JavaScriptのようなサーバサイドもクライアントサイドもどちらも記述できる言語を使うときによくこの呼び方をするような気がします。
さて、原始的には1台のWebサーバと1台のWebクライアントで成り立っていたWebServieceですが、大規模化していくとそうはいきません。複雑化していくのは専らサーバサイドの方ですね。
サーバサイドはWebサーバだけではなく、動的なコンテンツ生成の必要性からアプリケーションサーバ（以下、APサーバ）、認証機能や商品情報を格納するためのデータベースサーバ（以下、DBサーバ）が必要となり、また、障害発生時にシステムが止まってしまわないためにもそれらを冗長化や負荷分散させる必要があります。
ただ本書では、どれだけ複雑化するサーバサイドのシステムでも論理的にはWebサーバとAPサーバとDBサーバの3種類に分けられると記載されており、これらの構成を三層構成と呼んでいます。
では、この3種類のサーバについてそれぞれ見ていきましょう。
まず、Webサーバについて、これはWebServiceのコンテンツを格納するサーバになります。具体的にはHTML・CSS・JavaScriptファイル等を格納したりAPサーバと連携するモジュールを準備したりするもので、WebServiceの外見を構成するインターフェース用のサーバになります。前述しましたが主要なソフトウェアはApacheやNGINXとなります。
次に、APサーバについて、これは動的コンテンツ生成のために用いられるサーバであり、様々な言語で記述されています。PHPもあればJava、Pythonであることもあるでしょう。なのでAPサーバに決まったソフトウェアというのはありません。OSはLinuxであることが多いでしょうが、上にのるソフトウェアは多種多様です。APサーバの役割も多岐にわたるので一様に説明するのは難しいですが、コンテンツを動的に変更したり、DBサーバからデータを取得したり様々な役割を担います。
最後に、DBサーバについて、これは膨大なコンテンツのデータや利用するユーザの認証情報などを格納するサーバになります。小規模なWebServieceならWebサーバに直接データを記述しても良いのかもしれませんが、大規模なWebServieceは数億以上のデータを保持する必要があります。例えば、Amazonのショッピングサイトを考えてみてください。全ての商品情報とユーザ情報、販売代理店情報をWebサーバに保持するのは難しいです。そこで考案されたのがDBMSというシステムです。
DBMSとは、DataBaseManagementSystemの略であり、データを効率的に格納するシステム体系のことです。
ここでシステム体系というのは、データの格納構造とデータの操作言語を合わせたものを表します。データはいたずらに格納されるだけではいろいろと不便です。収納だって整理されていた方が使い勝手が良いのと同じですね。
DBMSについて詳述しようとすると、本1冊くらい書けてしまうのでここでは割愛します。
主要なDBMSだけ紹介しておくと、OracleDBやMySQL、PostgreSQLが挙げられます。しかし、近年ではAWS独自のDBであったり、NoSQLというものが台頭してきたりしているので、しっかりと腰を据えて学習していく必要がありますね。
これらのサーバの組み合わせでいくらでも複雑で大規模なサービスが構築できるのです。
6章
本章では、アーキテクチャとフレームワークについて記されています。
アーキテクチャというのは直訳で建築様式であり元々は建築用語なのですが、Webサービスでも共通した設計様式という意味になります。
建築でも、和式・洋式・クラシック・モダンといった様式に従って建築方法に共通したモデルがあるように、Webサービスでも設計するものによって共通したモデルを適用します。
その代表的なアーキテクチャがMVCモデルとなりまｓ。
MVCモデルというのは、Model・View・Controllerの頭文字を取ったものになり、それぞれの機能ごとにプログラムを分離する設計手法となります。
まず、ModelというのがWebサービスの処理を担当する部分になっており、ログイン処理であったり、DBの操作などを実装します。コンピュータの3大機能であるIPO（Input：入力、Process：処理、Output：出力）で言うとProcessに相当します。
次に、ViewというのがWebサービスの画面表示を担当する部分になっており、HTMLの生成などを実装します。IPOで言うとOutputに相当します。
最後に、ControllerというのがWebサービスの制御を担当する部分になっており、ユーザからの入力処理、Modelへのパラメータ渡し、Viewの呼び出しなどを実装します。IPOで言うとInputに相当します。
これらアーキテクチャはあくまで設計様式であり、実際の手段ではありません。
アーキテクチャの思想を反映して、実際に手段化されたものがフレームワークとなります。
フレームワークとは、あらかじめ規定されたプログラム群の中に、サービスに即して個人のコードを埋め込んで使うもので、言語によって様々なものが存在し、一番有名なものだとRubyのRails、次にPHPのLaravelが人気です。
私はよくPythonを使うので、PythonのフレームワークであるDjangoだと、あらかじめURLやViewやModelを記載するプログラムが与えられていて、そこにCodeを埋め込んでいくような形になっています。
7章
本章では、Webサービスのセキュリティに関して記されています。
これまでの章で学んだ技術を活かしてせっかく作ったWebサービスが悪用されないためにもセキュリティについて考えることがとても意義深いことだと思います。
Webサービスというのは、Internet上に建設する建造物のようなもので、鍵もかけずに放置しておくといつの間にか悪者に好きなように利用されるなんてこともざらに発生します。
本書ではサイバー攻撃の一例として、SQLインジェクションやXSS(CrossSiteScripting)、セッションハイジャック等を紹介しております。
他にもサイバー攻撃の種類は山ほどあるので興味のある方は一度サイバー攻撃で検索してみてください。
また、フレームワークを使えば一からセキュリティに関するプログラムを実装しなくても、認証・認可やセキュリティ周りの機能を実装できるものもあるので一度確認してみてください。
おわりに
本書を読むことでWebサービスを作る仕組みが理解できたと思います。
なので、後はひたすら実践あるのみですね。
それでは、好きな言語と好きなフレームワークを選んで、いざものづくりの世界に旅立ちましょう。