WEBアプリケーションの概要

WEBアプリケーション とは、ブラウザから利用可能なアプリケーション・サービスのことを指します。
クライアント側のブラウザとサーバ側のアプリケーションサーバなどのプログラムが、 互いに通信をおこなうことでサービスを実現します。

一般的に、クライアントとサーバは以下のように構成されます。

WEBアプリケーション概要

クライアントでは、Internet Explorer、FirefoxなどのWEBブラウザが動作します。 ブラウザがユーザとのインタフェースとなります。

ユーザはブラウザに、WEBアプリケーションのURLを指定し、サーバへのリクエスト(要求)を送信します。
その後、ブラウザはサーバから受け取ったレスポンス(応答)に基づいて画面を構築し、 ユーザからの入力に応じてサーバへのリクエストを発行することでWEBアプリケーションの機能を実現します。


サーバでは、データの蓄積のためにデータベースサーバが、 これらのデータを処理するロジックとしてアプリケーション (および、それを動作させるプラットフォームとして、アプリケーションサーバ) が動作します。

サーバは、ブラウザから受信したリクエストに応じて処理をおこない、 ユーザに提示すべき内容などをレスポンスとしてクライアントに送信します。

クライアント-サーバ間の通信

URL

WEBアプリケーションの場所を示したり、WEBアプリケーションに対して値を渡す場合には URL(Uniform Resource Locator) が使用されます。
インターネットにおいて、サーバが提供するWEBアプリケーションなどのサービスやファイルは リソース と呼ばれ、URLによってその場所が識別されます。

URLは、一般的に以下のような形式で表現されます。
(ここではよく使われる要素のみを説明します。詳細は RFC1738 を参照してください。また、今回はHTTPのみで、HTTPS(セキュアなHTTP接続)に関しては説明しません。)

絶対URL表現
http://(サーバ名)[:(ポート番号)]/(絶対パス)[?(クエリ)]

相対URL表現
(相対パス)[?(クエリ)]

絶対URL表現 とは、サーバの場所からパスまで、リソースの識別に必要なすべての情報をURLとして記述する方法です。
ユーザがブラウザにURLを入力しリソースにアクセスする場合は、絶対URL表現によってリソースの位置が指定されます。
また、あるリソースから別のサーバにあるリソースを参照する場合なども、絶対URL表現が使用されます。

相対URL表現 とは、あるリソースを起点に別のリソースの相対的な位置をURLとして記述する方法です。
主に、あるリソースから、同じサーバにある別のリソースを参照する場合に使用されます。

URLは以下の要素から構成されます。

要素 意味
サーバ名 www.google.co.jp, 192.168.0.1, localhostなど リソースがあるサーバの名前を指定します。
一般的には以下のいずれかの形式で指定します。
  • IPアドレス(192.168.0.1など)
  • DNSによって提供されるホスト名(www.google.co.jpなど)
  • ローカルループバックアドレス(localhost,127.0.0.1のいずれか。自分自身を指す)
ポート番号 80, 8080など リソースがあるサーバのポート番号を整数で指定します。
ポート番号80でリソースが公開されている場合、ポート番号は省略可能です。

絶対パス・相対パス index.html, sample/test.htmlなど サーバ内のリソースの場所を指定します。
ディレクトリ名、ファイル名はスラッシュ(/)で区切ります。

クエリ sample=test, a=b&c=dなど リソースに関するパラメータを指定します。
ユーザの入力した内容など、リソースに対してパラメータを渡したい場合に使用します。

本教材ではサーバおよびブラウザが同一のマシンで動作することを想定していますので、サーバ名はlocalhostとなります。
また、Tomcatはデフォルトでポート番号8080でインストールされます。
パスおよびクエリはWEBアプリケーションによって異なりますので、必要に応じて説明していきます。

HTTP

クライアント-サーバ間のリクエストおよびレスポンスは HTTP(HyperText Transfer Protocol) に則って表現されます。
なお、HTTPの処理はすべてアプリケーションサーバがおこなうため、開発者はHTTPの知識を必要としませんが、 ここでは基礎として簡単に説明します。

リクエストおよびレスポンスは、一般的に以下のような形式で表現されます。
(ここではよく使われる要素のみを説明します。詳細は RFC2068 を参照してください。)

リクエスト
(メソッド) (リクエストパス) HTTP/1.1
(ヘッダ名): (値)
...

(メッセージ本体)

レスポンス
HTTP/1.1 (ステータスコード) (ステータス文字列)
(ヘッダ名): (値)
...

(メッセージ本体)

リクエスト・レスポンスともに、大きく分けてヘッダ部とメッセージ本体の2箇所からなります。
ヘッダ部にはリクエスト・レスポンスに関する情報が文字列で記述され、 メッセージ本体にはリクエスト・レスポンスのデータが記述されます。

各要素の説明は以下の通りです。

要素 意味
メソッド GET, POSTなど リソースの取得方法を指定します。GETはリクエストURLの内容を取得することを示し、POSTはメッセージ本体に格納されたパラメータをリクエストURLに与えることを示します。

リクエストパス /sample/test.htmlなど リクエスト対象のリソースを示すパスを指定します。
ここにはリソースのサーバ内での絶対パスを指定します。

ヘッダ名・値 Content-Type: text/html;charset=Shift_JISなど リクエスト・レスポンスに関する情報を指定します。
レスポンスのタイプ(HTML/PNG画像/...など)や文字エンコーディング、キャッシュしてよいリソースかどうかなどの情報が記述されます。

ステータスコード 200, 404, 500など リクエストの結果を表す整数値が格納されます。
例えば、200ならばリクエストの処理成功を示し、メッセージ本体にリクエストされた情報が格納されます。
404ならばリクエストされたパスが存在しないことを示します。

ステータス文字列 OK, Not Found, Internal Server Errorなど リクエストの結果を表す文字列が格納されます。
例えば、ステータスコード200ならば「OK」が、ステータスコード404ならば「Not Found」が格納されます。

メッセージ本体 HTML,画像など リクエストの場合、メソッドがPOSTである場合はPOSTするパラメータが格納されます。
レスポンスの場合、リクエストされたリソースの内容が格納されます。