REST（表現状態の転送）とは：定義・原則・RESTful設計の仕組み

RESTの定義と原則を図解でわかりやすく解説。RESTful設計の仕組みや実例、実装ポイントまで初心者〜実務者必見。

REST（Representational State Transfer）は、分散システム間で効率的かつ拡張可能にデータや機能をやり取りするためのアーキテクチャスタイルです。リソース（データやサービスの対象）を一意に識別し、そのリソースの「表現（Representation）」をやり取りすることで、状態の転送（State Transfer）を行います。リソースそのものの完全な複製を多数作るのではなく、参照（URI）や必要な表現をやり取りしてオンデマンドで利用するという考え方に基づいており、これを満たすシステムを一般に「RESTful」と呼びます。

RESTの基本概念（リソースと表現）

RESTでは「リソース」が中心概念です。リソースは抽象的な対象（ユーザー、商品、注文など）で、通常は一意の識別子（URI）で表されます。クライアントはそのURIを通じてリソースにアクセスし、サーバーはリソースの現在の状態を表した表現（JSON、XML、HTMLなどのメディアタイプ）を返します。クライアントはその表現を基に操作や表示を行い、必要であれば別の表現（例えばJSONからHTML）を要求することもできます。

わかりやすい比喩（非RESTfulとRESTfulの違い）

非RESTfulな実世界システムの例として、従来のホームムービーのコレクションがあります。任意の映画にアクセスするためには、図書館の所有者はその映画の物理的なコピーを入手しなければなりません。これでは、その時点で使用されている数よりも多くのコピーが存在することになり、かなりの無駄が生じます。また、ライブラリに新しいタイトルを追加するのに必要な時間は、一般的に些細なことではありません。ストリーミング・ビデオは、ホーム・ライブラリーのRESTful対応版です。自宅に保存されているすべての映画の完全なコピーを持つ代わりに、映画はタイトルのみで参照され、映画の内容はオンデマンドでストリーミングされます。

World Wide Webは今日のRESTfulシステムの最大の例です。物理的なライブラリは、その非RESTfulに相当します。各デジタルリソースの物理的な電子コピーを各個人や図書館に送る代わりに、各リソースにURL識別子「http://example.com」を割り当て、光ディスクやハードドライブからローカルコピーを取得するのではなく、インターネットを介して実際のコンテンツにアクセスします。

REST アーキテクチャは、他の文脈でも適用することができます。例えば、常に変化する複数のギガバイトの情報を共有したいと考えている2つの企業を考えてみましょう。お互いのデータベースの完全なコピーを定期的に（インターネットを介してでも）送信するのは、無駄で時間のかかるプロセスです。この情報共有の方法は、先に挙げた図書館の例に似ています。その代わりに、企業間でデータベースIDを共有し、データベース内の各アイテムに独自のURLを割り当てることもできます。一方の会社が他方の会社に属する特定のアイテムの価格をデータベースに照会したい場合、その特定の在庫アイテムのデータを取得することができます。

RESTの原則・制約（アーキテクチャスタイル）

• クライアント–サーバーの分離：クライアント（UIや利用者のロジック）とサーバー（データ管理と処理）を明確に分離することで、各側の独立した進化とスケーラビリティを可能にします。
• ステートレス（無状態）：各リクエストは完結しており、サーバー側でクライアントのセッション状態を保持しません。状態は必要ならクライアント側で保持するか、明示的なトークンでやり取りします。
• キャッシュ可能：レスポンスは明示的にキャッシュ可能であるか否かを示し、正しくキャッシュ利用することでパフォーマンスを向上させます（HTTPのCache-Controlなど）。
• 統一インターフェース（Uniform Interface）：リソースの識別（URI）、リソースの表現、標準的な操作（HTTPメソッド）など一貫したインターフェースにより、システムの単純さと相互運用性を実現します。
• 階層化システム：アーキテクチャを複数の層（プロキシ、ゲートウェイ、負荷分散など）に分け、各層は独立して設計・運用できます。
• コード・オン・デマンド（任意）：必要に応じてサーバーがクライアントにコード（スクリプトなど）を送ることで、クライアント機能を拡張できます（オプション）。
• HATEOAS（Hypermedia as the Engine of Application State）：レスポンスに次に可能な操作へのリンク（ハイパーメディア）を含めることで、クライアントはサーバーの提供する状態遷移に従って動作できます（完全な実装は必須ではありませんが、RESTの理想形に近い機能を提供します）。

HTTPとREST：よく使われるメソッドと性質

RESTはしばしばHTTP上で実装されます。代表的なメソッドと性質は次のとおりです：

• GET：リソースの取得（安全で副作用がないことが理想）
• POST：リソースの作成やサブミッション（非冪等）
• PUT：リソースの完全置換または作成（冪等）
• PATCH：リソースの部分更新（通常は冪等として設計）
• DELETE：リソースの削除（冪等）

また、HTTPステータスコード（200、201、204、400、401、403、404、500 等）を適切に使って成功・失敗の意図を明確に伝えることが重要です。表現形式には一般的にJSONが多く用いられますが、用途に応じてXML、HTML、画像、バイナリなどのメディアタイプも利用されます。

RESTful設計のベストプラクティス

• リソース設計：URIは名詞（/users/123、/orders/2020-01）を使い、動詞はHTTPメソッドに任せます。
• 階層的で意味のあるURI：親子リソースを階層的に表現（/users/123/orders）し、リソースの関係を明示します。
• バージョン管理：破壊的変更にはバージョン付けを行う（例：/v1/users または Accept ヘッダでのバージョン指定）。
• ページング・フィルタリング・ソート：大量データはページング（limit/offset）、フィルタ、ソートをサポートして効率的に提供します。
• エラーハンドリング：標準HTTPステータスに加え、エラーの詳細を含むボディを返し、クライアントが復旧できるようにします。
• キャッシュ活用：Cache-ControlやETag、Last-Modifiedを利用して帯域とレスポンス時間を最適化します。
• 認証・認可：トークンベース認証（OAuth 2.0、JWTなど）やTLSを利用して通信の機密性と真正性を担保します。
• ドキュメント化：APIの仕様（OpenAPI/Swagger等）を用いて利用方法を明確にします。

RESTの制限と代替技術

RESTは汎用的で理解しやすい一方、次のようなケースでは別のアプローチが適することがあります。

• クライアントが必要なデータを細かく指定して一度に取得したい場合 → GraphQL（必要なフィールドだけを1リクエストで取得）
• 低レイテンシで大量の小さなメッセージをやり取りする必要がある場合 → gRPCやWebSocket
• 厳密なトランザクション管理や複雑なWS-*仕様が必要な企業統合 → SOAP

まとめ

RESTは「リソース」を中心に、表現をやり取りして状態を遷移させるシンプルで強力なアーキテクチャスタイルです。正しく適用すればスケーラブルで保守性の高い分散システムを構築できますが、要件によってはGraphQLやgRPCなどの別の手法が適する場合もあります。基本原則（無状態、統一インターフェース、キャッシュ可能など）を理解し、HTTPの特性（メソッド、ステータスコード、ヘッダ）を活用することが、良いRESTful API設計の鍵です。

質問と回答

Q: Representational State Transfer (REST)とは何ですか?

Q: RESTを実装したシステムは何と呼ばれていますか?

Q: RESTを使ってコンピュータシステム同士はどのように通信するのですか?

Q: RESTは何を文書化するのですか?

Q: REST（Representational State Transfer）というソフトウェアアーキテクチャースタイルを作ったのは誰ですか?

Q: RESTはどのような通信方式を採用していますか?

Q: REST（RepresentationalStateTransfer）の目的は何ですか?

文字で検索