Webの全体像を把握した上でWebアプリケーションの根幹を理解する

前記事
書籍を通じて、Webの技術的発展と歴史的背景から全体像を把握する
の続きです。

Webアプリケーションの根幹を成すのはHTTP通信

Webアプリケーション開発において、Webアプリケーションフレームワークを利用して開発が進められていきました。
このWebアプリケーションフレームワークを利用するとHTTPを通信についてあまり詳しくなくてもWebアプリケーションを作る事が出来てしまいます。

しかし、何か不具合が起きた時にHTTP通信に関しての知識がないと原因の特定が出来ません。
これからWeb技術に携わる専門家となるのであれば、仕組みをきちんと理解しなくてはいけません。

HTTPとは何か、という所までは深堀りしません。
OSI参照モデルや、TCP/IPモデルといった所まで引き合いに出さなければいけなくなりそうなので、
基本的なHTTP通信周りの知識をある程度持っているという前提で書き進めます。

WebアプリケーションへHTTP通信を用いて情報を渡すための方法

大きく分けて2つあります。
GETメソッドとPOSTメソッドです。
本当にすごーく簡単かつ分かりやすく説明させて頂きます。

GETメソッド

値(パラメータ)をURLにくっつけてWebサーバに送るという事。
値(パラメータ)というのは、クエリ文字列内のパラメータ名や値の事を指します。
1 + 1 = 2 という計算ウィンドウがあったとして、その計算プログラムのやり取りがURLに表示されてしまうということです。
また、GETメソッドでユーザIDやパスワードをやり取りすればURLに表示されてしまうという事でもあります。
※URLに表示されるという事はアドレスバーに見えるという事です。

POSTメソッド

GETメソッドとは違い、値を見えないようにくっつけてWebサーバに送る事。
GETメソッドからPOSTメソッドに変えたからといって利用者から見れば変わりはありません。
裏で処理された時のやり取りがURLに表示されるのではなく、サーバにリクエストを送る際のメッセージボディに記述されます。
URLに表示されない事で第3者に見られてしまう可能性が少ないということになります。
また、メッセージボディには記述の長さ制限がないのでパラメータの量が多い場合でも長さの心配をする必要がないということです。

GETメソッドとPOSTメソッドの使い分け

結局どちらを使えばいいのかという話になると思います。
GETメソッドにおけるパラメータがURLに表示されてしまうデメリットを上げましたが、URLに表示されるというのはメリットでもあります。
Amazonの商品情報を共有する時や、Youtubeで面白い動画をシェアしたい時にはURLをコピーしてそれを共有する事ができ、パラメータごとに記憶したり人に伝える点で便利です。
一方POSTメソッドには上記の方にブックマークを利用したパラメータの保存は出来ません。
なので、一概にPOSTメソッドを使えばいいと言うわけではないというのは分かると思います。

パラメータ毎に保存する事が出来る利点を活かせる場合にはGETメソッドを利用し、
ログイン処理のような機密情報を送信する場合や、クエリ文字列に収まりきらない大量の情報を送信する必要がある場合にはPOSTメソッドを使うといった使い分けが必要になるということになります。

HTTP通信の特徴

「HTTPは状態を持てない」という特徴を持っています。
ステートレスなプロトコルと表現されます。
これはどういう事かというと、例えば、Webサイトに一度ログインした後のURLが「hoge.co.jp/item_list」と表示されていたとします。このURLを他の誰かが打ち込んだ場合、本来ユーザ名とパスワード入力してからでないと入れないページに飛ぶ事が出来てしまうということです。
GETメソッドではURLにパラメータが表示されてしまうので工夫したとしても少し想像力を働かせれば仕組みに気付かれるリスクがあります。
一方POSTメソッドではこの問題を解消する事は出来ますが、毎回ログインを必要とするフォームを設置しなくていけませんし、これでは利便性が大きく損なわれてしまいます。

Cookieという技術の誕生

そこで考えられたのがCookieです。
仕組み自体は比較的簡単なものです。
WebサーバからWebブラウザへHTTPレスポンスのヘッダを利用して小さな情報を送ります。この小さな情報というのが「名前=値」の組み合わせで表され、Cookieと呼びます。
Cookieを受け取ったWebブラウザは、次回同じWebサーバにアクセスする際、受け取ったCookieをそのままHTTPリクエスト・ヘッダに入れて送ります。
本来状態を持たないHTTP通信は毎回ブラウザに対して「はじめまして」という状態だったのが、リクエスト・ヘッダ内のCookieを調べる事でアクセスした相手がどのような相手なのか知る事が出来るということです。
一方、Cookieを受け取ったあとでも、Cookieを受け取ったサーバとは異なるWebサーバに対してはCookieを送りません。この仕組みによって、意図しない情報が他のWebサーバに送られてしまうのを防いでいます。

Cookieの問題点

全て解決したと思いましたが、まだ問題が残っていました。
セキュリティ上の問題です。
Cookieを利用した情報のやり取りはHTTPのリクエスト・ヘッダやレスポンス・ヘッダを利用して行われます。
ちょっと知識がある人ならば「IneySpy」のようなツールを用いて簡単に覗かれてしまうという事が起こってしまいます。

セッションの仕組み

Cookieの問題点を解決する為にセッションと呼ばれる仕組みが考え出されました。
セッションIDと呼ばれるものを発行します。
Cookieの時と同じようにレスポンスの際に発行しますが、HTTPレスポンスのCookieへ格納する形でクライアントに渡します。
そして以降のリクエストの時は、クライアントはセッションIDを格納したCookieをサーバへ送ります。
WebサーバはCookieを受け取ると、そこに格納されたセッションIDを元にしてクライアントの状態(ログイン状態やショッピングカートの中身)を復元します。

結局の所Cookieを利用してやり取りが行われます。
Cookieは「値=情報」だと説明しました。
Cookieの中に情報そのものを格納するのか、情報ではなくセッションIDとして格納するのかという所が大きな違いです。
セッションIDは非常に大きな桁数の数字であり、第3者に見られても問題ないというわけではありませんが、データそのものを格納することと比べると相対的に安全性が高いと言えるだけです。

まとめ

HTTP, Cookie, セッションは現在も使われている技術です。
特にCookie, セッションに関しては誕生の背景を知る事で理解を深められたと思います。
通信周りの詳しい説明は書籍や他の記事を参考にお願いいたします。
何か間違っている点があれば教えて頂けると幸いです。

参考書籍
プロになるためのWeb技術入門