「REST」って結局なに？インフラ屋が教える「クライアント・サーバー分離」の真髄
こんにちは！ネットワークの世界にどっぷり浸かって十数年、パケットの呼吸音が聞こえる気がするインフラアーキテクトです。
さて、今日はWeb APIの設計において避けては通れない「REST」という概念についてお話しします。「REST API」という言葉、API開発の現場では必ず耳にしますよね。でも、教科書を開くと「4つの原則」だの「制約」だの、なんだか堅苦しい言葉が並んでいて、眠くなってしまった経験はありませんか？
今回は、その中でも特に重要で、かつインフラ屋の視点から見ても非常に理にかなっている「クライアント・サーバー分離」という原則を、専門用語を一切使わずに紐解いていこうと思います。
—
そもそも「クライアント・サーバー分離」って何？
一言で言えば、「役割分担を徹底しようぜ！」という話です。
皆さんの手元にあるスマホやPCが「クライアント」、遠くにあるデータセンターのサーバーが「サーバー」。この二つが、互いの仕事に口出ししないようにしましょう、というのがこの原則の狙いです。
これを身近な例で例えてみましょう。「郵便配達」を想像してください。
郵便配達で例えるなら…
- クライアント（ユーザー側）： 「手紙を書く人」です。便箋に内容を書き、封筒に入れ、宛先を書きます。
- サーバー（データ側）： 「郵便局」です。手紙の中身が何であれ、宛先さえ正しければ、その手紙を届けるという「配送」の仕事だけに集中します。
もし、郵便局員がいきなり「この手紙の内容、もっとこうした方がいいよ！」なんて添削を始めたらどうなるでしょう？ おそらく、郵便局はパンクし、手紙も届かなくなりますよね。
これと同じで、「表示や操作はクライアントの仕事」「データの管理や計算はサーバーの仕事」と完全に切り分けることで、システムは爆発的に進化しやすくなるのです。
—
なぜ「分離」すると嬉しいのか？（インフラ視点のメリット）
この「分離」ができていると、インフラエンジニアとしては夜もぐっすり眠れます。理由は大きく2つあります。
1. 別々にスケール（強化）できる
もしサーバーが「画面の表示」まで担当していたら、ユーザーが増えた時に、画面の描画処理とデータ処理の両方を強化しなければなりません。しかし、分離されていれば「データ処理が重いから、データベースサーバーだけ増強しよう！」という柔軟な対応が可能になります。
2. 進化のスピードが上がる
例えば、クライアントを「スマホアプリ」から「Webブラウザ」に変えたい時、サーバー側のデータ構造さえ同じなら、サーバーを一行も書き換える必要はありません。これって、ものすごいメリットだと思いませんか？
—
現場で使うコードで確認してみよう
実際に、どのようにして「役割分担」が行われているか、Pythonを使った非常にシンプルな例を見てみましょう。
# サーバー側のイメージ：データを提供することに特化する
# サーバーは「どんな画面で表示するか」は一切知りません。ただJSONという形式でデータを返すだけです。
def get_user_info():
# データベースから取得したデータだと想定してください
user_data = {
"id": 1,
"name": "インフラ太郎",
"role": "Network Engineer"
}
return user_data # データの純粋な箱だけを返す
# クライアント側のイメージ：受け取ったデータを使って「料理」する
# 受け取ったデータを、どう表示するかはクライアントの自由です。
data = get_user_info()
print(f"ユーザー名: {data['name']}") # 画面にどう出すかはクライアントが決めるこのように、サーバーは return するデータ（JSONなど）を用意するだけ。それを受け取って、スマホの画面に表示するのか、PCのグラフにするのか、あるいは機械が読み取るのかは、クライアントが決める。これが「クライアント・サーバー分離」の現場の姿です。
—
インフラ屋からのアドバイス
これからAPIを設計する皆さんに、一つだけアドバイスがあります。
「サーバーに『画面の都合』を持ち込まないでください」
初心者のうちは、つい「スマホアプリで見やすいように、サーバー側でHTMLタグを混ぜて送っちゃえ」と考えがちです。でも、それをやってしまうと、後で「やっぱりWebブラウザでも見たい！」となった時に、大掛かりな改修が必要になります。
サーバーは、ただ「データ」という純粋な荷物を、決まった住所（URL）に届けるプロフェッショナルであるべきです。
—
まとめ
- クライアント・サーバー分離は、お互いの領分を侵さないという「大人の約束」。
- 役割を分けることで、システムは柔軟になり、故障にも強くなる。
- サーバーは「データ」を返し、クライアントは「体験」を作る。
RESTの原則は、一見難しそうに見えて、実は非常にシンプルで美しい設計思想です。次にAPIを触る時は、「今、自分はサーバーの役割をしているかな？ クライアントの役割をしているかな？」と意識してみてください。
それだけで、皆さんが書くコードや構築するネットワークは、格段に美しく、そして強固なものに変わっていくはずですよ！
次回は、この続きとして「ステートレス（状態を持たない）」という、インフラ屋が泣いて喜ぶ原則について深掘りしていこうと思います。それでは、良いエンジニアライフを！
コメント