そもそも「サーブレット」って何者？
「サーブレットって何？」って聞かれると、“HTTPリクエストを受け取ってレスポンス返すやつ”くらいしか言えないんだよね。
その答え、実務的には100点。でも哲学的には30点。まず言葉を解剖しよう。
語源：Servlet = Serve + let
「Servlet」は Serve + let の合成語。
- serve：提供する、仕える
- -let：小さいもの（book → booklet、pig → piglet）
つまり直訳すると、
「小さなサーバー」
ここで一度立ち止まるのが重要。
小さなサーバー？
Tomcatとかがサーバーじゃないの？
その違和感、正しい。
ここで「サーバーとは何か」が分岐点になる。
サーバーとは何か（哲学編）
「サーバー」って言葉、実は2つの意味が混ざってる。
- 物理・論理的なサーバー（マシン、プロセス）
- リクエストに応答する存在
Servlet が指すのは 2番目。
つまり「HTTPリクエストを受けて、何かを返す存在」？
そう。それが“サーブする”という行為。
だから Servlet はこう言い換えられる。
「リクエストに応じて動く、小さな処理単位」
なぜ「小さい」のか？
でもさ、今のWebアプリって巨大じゃない？
そこがポイント。
昔のCGI時代を想像してみて。
- リクエストが来る
- プロセスが起動する
- 処理が終わる
- プロセスが死ぬ
毎回これだとめちゃ重い。
あー、fork地獄。
そう。そこで Sun が考えた。
「常駐する軽い部品が、リクエストごとに動けばよくない？」
それが Servlet。
- 常駐してる
- 小さい
- 必要なときだけ呼ばれる
だから “let”（小さいやつ）。
Servletの正式な定義（ちゃんとしたやつ）
技術的に言うとこう。
Servletとは、サーバー上で動作し、クライアントからのリクエストを処理してレスポンスを生成するJavaクラス。
ポイントは3つ。
- サーバー上で動く
- リクエスト駆動
- Javaで書かれる
じゃあTomcatは？
Tomcatは「Servletを動かす環境」。
正式には Servletコンテナ。
Servletコンテナという黒幕
Servletは単体じゃ生きられない。
ライフサイクル管理を全部やってくれる存在が必要。
それが Servletコンテナ。
- インスタンス生成
- init() 呼び出し
- リクエストごとの service()
- destroy()
全部コンテナの仕事。
つまり Servlet は「雇われ労働者」？
まさにそれ。
Tomcatは会社。Servletは社員。
なぜ今もServletなのか？
でも今はSpring MVCとか使うじゃん？
ここが一番誤解されるところ。
Spring MVC も、裏では Servletの上に立ってる。
HTTPリクエスト
↓
DispatcherServlet（←これもServlet）
↓
ControllerServletは「土台」。
地味だけど、全てを支えてる。
本質的な定義
ここまでを一文にするとこう。
Servletとは「HTTPという会話に、状態を持たずに応答するための最小単位」
- 状態を持たない（基本は）
- リクエスト駆動
- 生存管理は他者任せ
これはまるで――
禅僧のような存在。
必要な時だけ現れて、仕事をして、消える。
サーブレットは偉大な存在だね
たとえ話
Servletを「飲食店」に例えると、
- Tomcat：建物・店長・インフラ全部
- Servlet：厨房の料理人
- HTTPリクエスト：注文
- レスポンス：料理
料理人は注文が来た時だけ動く。
店の経営はしない。
でも料理の質は、すべて彼にかかっている。
まとめ
- Servlet = Serve + let（小さなサーバー）
- HTTPリクエストを処理する最小単位
- 常駐するが、自分で生きてはいない
- コンテナに管理される存在
- 現代フレームワークの土台
