クライアントとサーバーを一言でいうと
クライアントとサーバーは、
「お願いする側」と「応える側」です。
ブラウザやスマホアプリが クライアント、
そのリクエストを受け取って処理するのが サーバー。
Web の世界は、この二者が HTTP という共通ルール を使って会話しているだけ、と言ってもいいくらいです。
ここを腹落ちさせると、Java で Web アプリを書くときの全体像が一気にクリアになります。
クライアントとは何者か
「画面を持っている側」
クライアントは、ユーザーと直接向き合っている存在です。
ブラウザ（Chrome、Edge、Safari など）、スマホアプリ、デスクトップアプリなどがクライアントになります。
クライアントの主な役割は、
ユーザーに画面を見せる
ユーザーから入力を受け取る
必要なタイミングでサーバーにリクエストを送る
サーバーからのレスポンスを画面に反映する
といった「見た目」と「操作」の部分です。
Java の世界でも、
「サーバーサイド Java（Spring など）」と
「ブラウザ側の JavaScript」
という分担で動いていることが多いですが、
“クライアント＝画面側” というイメージは変わりません。
クライアントの具体例イメージ
例えば、ユーザー一覧画面を考えてみましょう。
ブラウザは、
「ユーザー一覧を表示したい」と思ったタイミングで、GET /users という HTTP リクエストをサーバーに送ります。
その結果として返ってきた HTML や JSON をもとに、
画面に「ユーザー一覧」を描画します。
クライアントは「自分ではユーザー情報を持っていない」。
必要なたびにサーバーに聞きに行く。
この感覚がとても大事です。
サーバーとは何者か
「中身とルールを握っている側」
サーバーは、
クライアントからのリクエストを受け取り、
必要な処理を行い、
結果をレスポンスとして返す役割を持ちます。
Java で書くのは、基本的にこのサーバー側のロジックです。
サーバーの主な役割は、
ビジネスロジックの実行（料金計算、在庫チェックなど）
データベースとのやり取り（保存・検索・更新）
認証・認可（誰が何をしてよいか）
トランザクション管理（途中で失敗したらまとめて取り消す）
など、「システムの中身」の部分です。
Java Web アプリとしてのサーバー
Spring Boot を例にすると、サーバー側のコードはこんなイメージになります。
@RestController
class UserController {
private final UserService userService;
@GetMapping("/users")
List<UserResponse> list() {
var users = userService.findAll();
return users.stream()
.map(UserResponse::from)
.toList();
}
}
/users に対するリクエストが来たら、userService.findAll() でデータを取り、
それを JSON にして返す。
この「リクエストを受けて、処理して、レスポンスを返す」一連の流れが、
サーバー側 Java の仕事です。
クライアントとサーバーの会話：HTTP の役割
「共通言語」としての HTTP
クライアントとサーバーは、
人間で言えば「日本語で会話する」ように、
HTTP という共通ルールで会話します。
クライアントは、
「どの URL に」「どんなメソッド（GET/POST など）で」「どんな情報を」送るかを決めてリクエストを投げます。
サーバーは、
そのリクエストを受け取り、
「ステータスコード（200、404、500 など）」と
「ボディ（HTML や JSON）」を含んだレスポンスを返します。
Java の Web フレームワーク（Spring など）は、
この HTTP のやり取りをいい感じに隠してくれて、
「メソッドとして書けば勝手に HTTP に乗せてくれる」ようにしてくれています。
クライアントとサーバーの責務分担
どっちが何をやるのか
ここが設計の肝です。
クライアント側（ブラウザ・アプリ）は、
画面表示
ユーザー入力
簡単な入力チェック（必須項目、形式チェックなど）
サーバーへのリクエスト送信
サーバー側（Java）は、
ビジネスルールのチェック（このユーザーはこの操作をしてよいか）
データの整合性チェック（在庫が足りるか、重複していないか）
データベースとのやり取り
ログ記録、監査、トランザクション
というように、
「見た目」と「中身」をきれいに分けるのが基本です。
よくあるアンチパターン
クライアント側でビジネスルールを全部チェックしてしまう
サーバー側で画面の細かい見た目まで決めようとする
こうなると、
変更に弱くなり、
フロントとサーバーの責務がぐちゃぐちゃになります。
モダンな設計では、
クライアントは「画面と操作」、
サーバーは「ルールとデータ」、
という分担を意識します。
Java 初心者がまず持つべきイメージ
「ブラウザ → サーバー → DB → サーバー → ブラウザ」
例えば、「ユーザー一覧画面」を開く流れを、自分の言葉で描いてみましょう。
ブラウザ（クライアント）が /users に GET リクエストを送る
サーバー（Java）がそのリクエストを受け取る
サーバーが DB からユーザー一覧を取得する
サーバーがその結果を HTML や JSON にしてレスポンスとして返す
ブラウザがそれを受け取って画面に表示する
この一連の流れを、
「クライアントがお願いして、サーバーが応えている」
という視点でイメージできれば、
Web アプリの土台はもうできています。
まとめ：クライアントとサーバーを自分の言葉で説明するなら
あなたの言葉で整理すると、こうなります。
「クライアントは、ユーザーと向き合って画面を見せる側。
サーバーは、その裏でビジネスロジックやデータベース処理を担当する側。
両者は HTTP という共通ルールで会話し、
クライアントがリクエストを送り、サーバーがレスポンスを返すことで、
ログイン、一覧表示、登録、更新などの Web アプリの機能が成り立っている。」