Webはなぜ柔軟に動くのか？RESTのコードオンデマンドが支える仕組み

はじめに

REST では、複数のアーキテクチャスタイル（設計上の制約）を組み合わせることで、シンプルかつ拡張性の高いシステムを構築します。
その中の一つとしてあるのが、「コードオンデマンド」です。
本記事では、「コードオンデマンド」がREST全体の構成においてどんな役割を担っているのかを見ていきましょう！！

以下、関連記事もあるのでご覧ください！！

コードオンデマンドとは？

プログラムコードをサーバからダウンロードし、クライアント側でそれを実行するアーキテクチャスタイル。

コードオンデマンドの具体例

例）

Java、JavaScriptなどがこれに該当します。
例えば、WEBサイトの画像をアップロードする機能があるとします。
ユーザーが画像を選択してアップロードする際、リサイズや圧縮などの処理を、サーバーから配信されたJavaScriptコードによってクライアント側で実行することが可能です。

処理の流れ

1. リクエスト

ユーザーが「画像をアップロード」ボタンをクリックすると、クライアントはREST API（例：`POST /images`）を呼び出します。

2. レスポンス

サーバーは、アップロード処理に必要なJavaScriptコードをクライアントに返します。

3. コードの実行

クライアントは受け取ったJavaScriptを動的に実行し、画像の選択、プレビュー表示、リサイズ処理などを行います。

4. 結果の送信

最終的に、加工された画像データをサーバーに送信し、アップロード処理を完了させます。

このように、RESTのコードオンデマンド制約を活用することで、Webアプリケーションは必要に応じてクライアントに動的な機能を提供できるようになります。

コードオンデマンドの欠点

コードオンデマンドでは、クライアントがサーバーからコード（たとえばJavaScript）をダウンロードして実行することで、機能を動的に拡張できます。しかしこの方式には欠点もあります。

RESTでは、通常、クライアントとサーバーがHTTPというアプリケーションプロトコルに従って、明確なルールとインターフェースを通じて通信します。これにより、通信内容（どのリソースにアクセスし、どんな操作をしているか）が**第三者にも明確で、可視性が高い**という利点があります。

しかし、コードオンデマンドでは、サーバーが提供するプログラム（コード）の中で処理が実行されるため、**通信の意味やリソースへのアクセス方法がコードの内部に隠れてしまいます**。

その結果、通信の内容や意図がわかりづらくなり、**アプリケーション全体の可視性が低下する**というデメリットがあります。

例えば：

- クライアントが何の操作を行ったかが、外部ツール（APIログや監視ツール）では把握しづらくなる

- コードの内容を解析しないと、動作の全体像がわからない

このように、コードオンデマンドは柔軟さを提供する一方で、「透明性（トレーサビリティ）」の面では注意が必要です。

RESTにおけるコードオンデマンドの役割

コードオンデマンドは、RESTの6つのアーキテクチャ制約のうちの1つであり、**唯一のオプション（任意）制約**です。

この制約を導入することで、**サーバーがクライアントにコード（例：JavaScriptなど）を配信し、それをクライアント側で実行させる**ことができます。

これにより、以下のような効果が得られます：

- クライアントの機能を後から柔軟に拡張できる

- サーバー側で行っていた一部の処理を、クライアント側で実行させることで、サーバーの負荷を減らすことができる

- 必要な処理だけを動的に読み込むことで、初期読み込みを軽量化できる

つまり、コードオンデマンドは、クライアントとサーバーの役割分担の柔軟性を高め、
Webアプリケーションの拡張性や効率性を向上させる役割を担っています。

アーキテクチャ構成としての位置づけ

統一インタフェース/ 階層化システム / コードオンデマンド/クライアント/ キャッシュ / ステートレスサーバ

さいご

コードオンデマンドの制約により、クライアントの機能を柔軟に拡張し、処理負担を分散しながら、アプリケーションの柔軟性と効率性を高めることが期待できます。

おわりに：なぜRESTの制約を学んできたのか

紹介してきたRESTの6つの制約

（クライアント/サーバ、ステートレス、キャッシュ、統一インターフェース、階層化、コードオンデマンド）は、どれも今のWebが**大規模でも安定して動作している理由**につながっています。

私たちが毎日使っているWebサービスが、たくさんのユーザーに同時に使われても落ちない、わかりやすく動く、すばやく応答する――

それを実現しているのは、こうした**仕組みや考え方が、うまく組み合わされているから**です。

RESTの制約は、すべてを厳密に守る必要はありません。

でも「なぜこう設計されているのか」「なぜこれが役に立つのか」を知っていると、APIやサービスを設計するときに、RESTの制約を知っておくことで、サービスやAPIをしっかりとした土台の上で考えるヒントになるかもしれません。

当たり前のように使っているWebの裏側にある“支える力”が、少しでも見えてきたなら嬉しいです。

次回は、RESTと分散システムとの関係を見ていくことで、ハイパーメディアがRESTにどのような影響を与えるのか、WEBがなぜ世界規模の分散システムとして成功したのかを見ていきましょう！！