API

RESTを“語れる人”になる：HTTPのその先にある設計原則を解剖する

RESTを使っているのに、RESTが何かを正確に説明できない。そんな違和感が積み重なっていくと、自信のあるはずの設計にもどこか迷いが残る。RESTは使うものではなく、理解してこそ意味を持つ。その本質をつかむための記事。

RESTの設計思想はHTTPの背後にある

REST（Representational State Transfer）は、単なるAPIのルールではない。HTTPを含むWeb全体の設計思想を定義したアーキテクチャスタイルである。

2000年、Roy Fieldingが博士論文の中でこの概念を提唱した。彼はHTTP/1.1の共同設計者でもある。RESTは、分散システムがスケーラブルかつ一貫性のある構造を保てるように、クライアントとサーバーのやりとりの仕組みを形式化したものである。

Fieldingの言葉を借りるなら、「RESTはWebというシステムの成功に不可欠な原則を定義したもの」である。つまりRESTは、後からAPIの設計に取り入れられたのではなく、最初からWebの根底にあった設計論理に他ならない。

RESTの設計原則を正確に理解する

RESTには明確な設計原則が6つある。これらはAPIの仕様というより、分散システム全体をどう設計するかのルールとして機能している。

  • クライアント・サーバーの分離
    システムの構成要素を明確に分けることで、独立して進化できる。
  • ステートレス性
    リクエストごとに完全な情報を含めることで、サーバーが状態を保持しない。
  • キャッシュ可能性
    レスポンスは再利用可能に設計されることで、ネットワーク負荷を軽減する。
  • 統一インターフェース
    あらゆるリソース操作が共通のインターフェースで実現される。
  • 階層化システム
    サーバーを階層的に構築し、中継やゲートウェイの設計を可能にする。
  • コードオンデマンド（任意）
    クライアントにスクリプトを送ることで、一時的な拡張を可能にする。

特に重要なのは統一インターフェースの部分。これにより、あらゆる操作をGET、POST、PUT、DELETEなどのHTTPメソッドで一貫して行える。RESTful APIが「HTTPメソッドで操作する形式」を採用するのは、この原則に由来する。

RESTの中核は「リソース」と「表現」

RESTの最も重要な構造要素はリソースとその表現（Representation）である。URIで表されるものはすべてリソースとみなされる。たとえば /users/123 というURIは、IDが123のユーザーという「リソース」を指す。

ここで重要なのは、クライアントが受け取るのはリソースそのものではなく、その「状態を表したもの」であること。これを表現（Representation）と呼ぶ。

この関係を理解するために、宅配ピザに例える。

  • リソース：ピザの注文そのもの
  • URI：注文番号やチラシに書かれたコード
  • Representation：届いたピザ（大きさ、トッピング、箱の形）
  • HTTPメソッド：注文（POST）、確認（GET）、変更（PUT）、キャンセル（DELETE）

ピザを頼むたびに違う容器で届いても中身が同じならOK。RESTでも同じリソースに対して、JSONやXMLなど異なる表現形式が使える。中身が同じでも見せ方を変えられる。これがRESTの柔軟性につながる。

RESTful APIはRESTの応用形でしかない

RESTful APIはRESTの原則をHTTPにのせて実装した具体例にすぎない。つまりRESTそのものではなく、RESTという設計哲学に基づいた1つの表現形式である。

たとえば、GET /users/123 はRESTfulなエンドポイントだが、/getUser?id=123 のようなRPC的なAPIはREST的とは言えない。リソース中心ではなく、操作名が前に出ている設計だからである。

この違いは単なる書き方の話ではない。RESTは操作ではなく対象（リソース）に重心を置く考え方を前提としている。その視点が欠けると、設計全体が一貫性を失う。

RESTの設計思想はAPI以外にも活きている

RESTはAPI専用の設計スタイルではない。Webページ、IoT通信、分散システム、キャッシュ制御、URI設計など、あらゆるWebアーキテクチャに応用されている。

Google Cloudの設計ドキュメントでは、「REST原則は、あらゆる規模のクラウドサービスで再利用可能な構造を提供する」と明記されている。たとえばFirebaseやCloud StorageといったGoogleのクラウドAPIもREST設計を踏襲している。

RESTの「リソースをURIで識別し、表現をHTTPで返す」思想は、IoTデバイスの状態管理やCDNのキャッシュ設計にも活用されている。RESTはHTTPベースの設計を越えて、Webの根幹に近い位置で機能している。

まとめ

RESTはHTTPで操作するAPI仕様ではない。Web全体をどう設計するかを定めた設計思想である。その中核には、リソースを抽象化し、表現によってやりとりするという概念がある。

RESTful APIはその思想をAPIとして実装したものでしかない。RESTを語れるということは、URIやHTTPメソッドだけでなく、「なぜそう設計するのか」という背後にある意図まで理解している状態である。

 

理解の深さが、設計の一貫性を生み、迷いのないシステムへつながっていく。RESTを語れるということは、Webを設計できるということでもある。