はじめに

RESTには2つの側面があります。
前回は「RESTとハイパーメディアの関係」について解説しました。

本記事では、もう一つの側面である「RESTと分散システムの関係」について見ていきます。
分散システムの課題に対して、RESTがどのような考え方を取り入れ、どのような影響を受けたのかを考察していきます。

以下、関連記事です。

分散システムにおける課題

ネットワーク越しの関数呼び出しには、大きなオーバーヘッドがあります。

従来の分散システムでは、RPC（Remote Procedure Call）やCORBA、DCOMといった技術が使われてきました。

RPC（リモートプロシージャコール）：ネットワーク越しに関数を呼び出せる仕組み。
CORBA（Common Object Request Broker Architecture）：異なる言語やプラットフォーム間でのオブジェクト通信を可能にする仕組み。
DCOM（Distributed Component Object Model）：マイクロソフトによる、ネットワーク上のオブジェクト呼び出し技術。

これらの技術は、サーバー上の関数やメソッドを、あたかもローカル関数のように呼び出すことを目的としていました。

しかし、このような仕組みでは、次のような問題が発生します。

関数呼び出しが頻繁に発生すると、ネットワーク越しの通信が増え、処理の遅延や性能の低下が生じる
サーバーごとに異なるインタフェースを持ち、クライアント側でのライブラリ依存や互換性の問題が発生する
呼び出し単位の粒度が細かく、ネットワークでの利用に向いていない

RESTが解決するポイント

RESTでは、関数ではなくリソースを中心とした設計を行います。

リソースは「意味のあるデータのかたまり」として設計されており、やり取りするデータの粒度が大きい
クライアントはリンクをたどってリソースにアクセスし、状態を遷移させることでアプリケーションを実現する
統一されたインタフェース（URIとHTTPメソッド）により、どのサーバーでも同じようにアクセスできる

この結果、次のような利点が得られます

ネットワーク呼び出しの回数を減らし、性能劣化を抑えることができる
インタフェースがHTTPという標準に固定されているため、互換性や接続性に優れる
クライアントが特定のライブラリに依存せず、疎結合な設計が可能になる

RESTへの影響：分散システムの教訓から生まれた設計

RESTは、分散システムで繰り返されてきた問題点「通信コストの高さ」「システムの複雑さ」「インタフェースの非互換性」などに対する反省から生まれた設計スタイルです。

特に次の点において、分散システムの経験がRESTに大きな影響を与えています

細かすぎるAPI呼び出しはネットワークに不向きである → 粒度の大きなリソース設計へ
多様なインタフェースは保守性を悪化させる → 統一インタフェースの採用
状態を保持しない設計のほうがスケーラブル → ステートレスな通信モデル

つまり、RESTは、分散システムの現実的な課題に真っ向から向き合い、**「ネットワーク上でもうまく動作する仕組みとは何か？」**という問いへの解として形作られたスタイルだといえます。

RPCとRESTの違い

RESTを支える“分散システムの教訓”とは？失敗から生まれた設計思想をひも解く｜ShiftBブログ

RPCは「関数に対してPOST」を使う。RESTは「URLに対してPOST」を使う。

まとめ

分散システムの課題は、RESTの設計思想によって多くが解決されます。リソースを中心とした構造、統一されたインタフェース、リンクによる状態遷移などは、システムの柔軟性と効率性を大きく高めます。

RESTは、分散システムの限界を受け止めた上で生まれたスタイルです。だからこそ、ネットワーク越しでもスケーラブルに動作し、再利用性・保守性にも優れたAPI設計を実現できるのです。

RESTはWEB全体のアーキテクチャスタイルです。
WEBはRESTという分散ネットワークシステムのための理論があって、ここまで成功できたのではないでしょうか。
私たちが作るWEBサービスやWEB APIはWEBを構成する一部です。
個別のWEBサービスやWEB APIがRESTfullになると、WEBは全体としてより良くなります。
次回以降は、HTTP、URI、HTMLなどのハイパーメディアフォーマットをどのようにしてRESTfullに使うのか、
そしてWEBやWEB APIをRESTfullに設計するにはどうすべきかを見ていきましょう！！