アプリケーションサーバ

  • いわゆる アプリケーションサーバ; Application Server や APIサーバ; API Server と呼ばれるWebサーバの類型は、 静的なファイル内容の送信だけではなく、以下のような能力を持つWebサーバと言える
    • 動的なコンテンツ生成
    • リクエストに付随して、送信コンテンツの計算以外にも副次的な処理
      • リクエスト内容をもとに、サーバ側に何らかのデータを保存
      • メールを送信
      • 別のアプリケーションサーバに更にリクエストを送って連携した機能を実現
      • サーバ側に存在する大量のデータに対する バッチ; Batch 処理などの 非同期 処理を開始
      • これらを 副作用; Side-effect と言ったりする
  • API; Application Programming Interface はソフトウェア開発のあらゆるレイヤで登場する語
  • 動的なコンテンツ生成をする、ということは、 「リクエストの内容を元に、プログラムで定めた処理を行って、送信すべき内容を計算する」ことにほかならない
  • 従って、
    • そのサービスの開発者が、実現したい機能内容を自分たちでプログラムとして表現し、
    • かつ、そのプログラムがHTTP要求に対し正しい応答を行うことができる必要がある
      • ＝クライアントから見る限りにおいて、Apache HTTP Serverなどの既存製品と同等の要求処理をこなす
      • このように、特定のプロトコルに則った要求処理・応答ができることを指して、俗に 喋る と言ったりする
  • 当然ながら、InternetとWebのプロトコルスタックをすべて自前で実装するのは骨が折れる
    • ぼくにはとてもできない
  • そこで、それらの大部分を隠蔽し、開発者は本質的に実現したい機能だけ(「ビジネスロジック」と呼ばれたりする)をプログラムとして実装すれば、 あとは組み合わせて実行するだけでWebサーバとして振る舞うようになる、という フレームワーク; Framework が多数存在する

「動的生成」

  • 一口に「動的」といっても、HTTPリクエストに対し、何を起因としてコンテンツを変動させるかは様々
    • 時刻
    • 送信者(IP)
    • 送信者(認証; Authentication 情報)
    • 送信者に認められた閲覧・操作の権限; Privilege
    • 付加情報
      • HTTPでは、URL以外にも ヘッダ; header や body (文脈によっては payload とも)を付与できる
      • URLの一部として、リクエストごとに変動しうる情報を付与することもある(クエリ; query parameter/query string や fragment/hash)
    • 履歴
    • コンテンツの有効期限
    • etc...
  • 静的なファイルを送信するWebサーバでも、認証情報の有無による閲覧制限など、実行時設定だけで実現できることも多い
    • Basic認証 を用いた閲覧制限など。明確な定義が規定・共有されており、様々な製品で最初から実装済み
    • このような手法の適用は、動的生成とはまず言わない
  • 動的生成という場合は:
    • コンテンツをそのまま保存(永続化; persist)したファイル実体がWebサーバ上にあるわけではなく、
    • テンプレート(ひな型; Template) システムを用いて、表示内容の一部が変動する文書をひな型をもとに生成したり、
    • 後述する データベース に保存されているデータを、特定形式に シリアライズ; serialize したりして、
      • Serialize にはあまり良い訳語がない。 変換; convert といっても良いが、 「何らかの構造化されたデータを送信・保管のために都合の良い(多くは machine-readable な)形式に変換する」 というニュアンスでよく使われる
    • リクエストごとに送信するデータを構築する方式を指す
  • この辺は筆者の肌感で書いている。もっとちゃんとした定義があるかもしれない

アプリケーションサーバの構成要素

  • 本文書では大枠で既知としているHTTPには、リクエスト時に指定するGET/POST/PUT/DELETEなどの Method (動詞; Verb と呼ぶことも)が定義されている
    • それぞれが「どのような要求を意味するか」 「サーバは要求に対し何をすべき(SHOULD)か、あるいは何をしてはいけない(MUST NOT)か」がRFCに規定されている
      • 行儀の良い、正しく実装されたWebサーバアプリケーションやフレームワークは、こういった規定を遵守していることが多い
      • 開発者が自由に実装できるアプリケーションサーバも、当然RFCを遵守するほうが都合の良いことが多い
      • 演習2: 演習1で特定したRFCのどこかに、上記のような Method の定義がある。探して読んでみよう
  • アプリケーションサーバも、こうしたHTTPの枠組みの上で、機能実現を目指すことになる
    • もちろん、HTTP以外のプロトコルをベースにすることもある
    • TCP上に直接、独自のプロトコルを定義することもある(オンラインゲームなどでは日常的)
    • "Web"アプリケーションサーバといった場合には、暗黙にHTTPをベースにしたプロトコルを用いるアプリケーションサーバといった印象だが、 このあたりの単語はそれほど明確な使い分けがなされているわけでもない
  • ただし、HTTPの規定は一般的な内容を定めるに過ぎないので、 アプリケーション独自の要請に基づき、 リクエストの形式をアプリケーションサーバごとに定める 必要がある
  • 応答可能なMethodとURLの形式
    • 例) GET /items, POST /comments, GET /users/:user_id
      • 大抵の場合、アプリケーションサーバの ホスト名; hostname(例えばdev.to)は別で定義済みであることが多いので、 上記のようにパス部分で定義することが多い(フレームワークを使った実装の際に、あるいは API Documentation 上で)
      • 上記の:user_idという部分は、URLの中で変動しうる部分(いわば変数)を示す
        • この書き方は一部のフレームワークで実際にコード内で使用されるほか、 API Documentation にも表れる
        • ほかには、/users/<user_id>, /users/${user_id}などと書き表すこともある
  • 利用するheaderの種類、期待する値の形式
    • 例) Authorization - サーバに対して 認証 済みであることを示す何らかの文字列(トークン; Token)を伝えるのによく用いられる
    • このような、特別な意味を持つとされていて、用途・形式がRFCで標準化済みのheaderも多い
  • body/queryを利用するか、するならば期待する値の形式
    • 例) 「Bodyは JSON (JavaScript Object Notation) 形式で、 "password"フィールドに、文字列で、認証のためのパスワードを格納していること」など
    • Bodyの中身がどのような形式であるかを示す特別なheaderとしてContent-Typeがあり、 ここに MIME Type で正しく形式を表明しておくことで、クラサバ間で誤解なく大きなデータの交換ができる
      • これも「標準化されたheader」の一つ

results matching ""

    No results matching ""