REST（Representational State Transfer）

RESTとは

REST（Representational State Transfer）は、2000年にRoy Fieldingが博士論文「Architectural Styles and the Design of Network-based Software Architectures」で提唱した、Web分散システムのアーキテクチャスタイルです。HTTPプロトコルの仕組みを最大限に活用し、リソースをURL（URI）で識別してHTTPメソッド（GET, POST, PUT, DELETE等）で操作するシンプルな設計原則を定めています。

RESTの原則に準拠して設計されたAPIを「RESTful API」と呼び、現在のWebサービスやモバイルアプリケーション開発において最も広く採用されているAPI設計パターンです。そのシンプルさ、スケーラビリティ、言語非依存性により、マイクロサービスアーキテクチャの標準的な通信方式としても活用されています。

RESTの6つの設計原則（制約）

RESTは以下の6つのアーキテクチャ制約によって定義されます。これらの制約を満たすシステムが「RESTful」と呼ばれます。

1. クライアント・サーバー分離

ユーザーインターフェース（クライアント）とデータストレージ（サーバー）の関心事を分離します。これにより、クライアントの可搬性とサーバーのスケーラビリティが向上し、各コンポーネントを独立して進化させることができます。

2. ステートレス性

サーバーはクライアントのセッション状態を保持しません。各リクエストは、処理に必要なすべての情報を含んでいる必要があります。これにより、サーバーの水平スケーリングが容易になり、リクエストのルーティングやロードバランシングが簡素化されます。

3. キャッシュ可能性

レスポンスにはキャッシュ可能かどうかを明示する必要があります。適切なキャッシュ戦略により、ネットワーク帯域の節約とレスポンス速度の向上が実現します。Cache-Control、ETag、Last-Modifiedなどのヘッダーで制御します。

4. 統一インターフェース

RESTの最も重要な制約です。リソースの識別（URL）、表現によるリソース操作、自己記述的メッセージ、HATEOAS（Hypermedia as the Engine of Application State）の4つの副制約で構成されます。

5. 階層化システム

クライアントは直接接続しているサーバーが最終サーバーか中間サーバーかを区別できません。ロードバランサー、CDN、プロキシなどの中間層を透過的に挿入できます。

6. コードオンデマンド（オプション）

サーバーからクライアントに実行可能なコード（JavaScriptなど）を転送し、クライアントの機能を拡張できます。これは唯一のオプション制約です。

HTTPメソッドとCRUD操作

RESTful APIでは、HTTPメソッドがリソースに対する操作を表現します。

HTTPメソッド	CRUD操作	べき等性	例
GET	Read	○	GET /users/123
POST	Create	×	POST /users
PUT	Update（全体）	○	PUT /users/123
PATCH	Update（部分）	△	PATCH /users/123
DELETE	Delete	○	DELETE /users/123

REST APIのURL設計のベストプラクティス

• 名詞を使う：/users, /products（動詞ではなくリソース名）
• 複数形を使う：/users/123（コレクションは複数形）
• ネストは浅く：/users/123/orders（2階層まで）
• ケバブケース：/user-profiles（アンダースコアよりハイフン）
• フィルタリング：/users?status=active&sort=name
• バージョニング：/v1/users または Accept: application/vnd.api.v1+json

RESTの限界と代替技術

RESTは多くのユースケースに適していますが、いくつかの限界も指摘されています。

• オーバーフェッチ/アンダーフェッチ：固定的なレスポンス形式のため、必要以上のデータや不足するデータが返される → GraphQLが解決
• リアルタイム通信：HTTP のリクエスト-レスポンスモデルでは双方向通信が困難 → WebSocketが解決
• パフォーマンス：JSONテキストのシリアライゼーションオーバーヘッド → gRPC（Protocol Buffers）が解決
• N+1問題：関連リソースの取得に複数リクエストが必要 → GraphQLやJSON:APIが解決

2025-2026年の最新動向

REST APIとAIの融合が進んでいます。OpenAI、Anthropic、GoogleなどのAI APIはRESTful設計を基本としており、REST APIの知識はAIサービス活用に不可欠です。また、AIがREST APIドキュメントを理解して自律的にAPIを呼び出す「AIエージェント」パターンが普及しています。

HTMXの台頭により、REST APIから直接HTMLフラグメントを返すパターンが再評価されています。JSON APIの代わりにHTMLを返すことで、クライアントサイドのJavaScriptフレームワークへの依存を削減するアプローチです。

また、OpenAPI 3.1の普及が進み、JSON Schemaとの完全互換性によりAPI仕様の表現力が大幅に向上しています。API仕様からサーバー/クライアントコードの自動生成ツールも成熟し、開発効率が向上しています。

アーキテクチャスタイルとしてのメリット・デメリット

RESTはAPI実装というより「システム設計の指針」であるため、その評価はアーキテクチャレベルで捉える必要があります。

メリット

• 疎結合と独立進化：クライアント・サーバー分離とステートレス性により、フロントエンドとバックエンドを別々のチーム・別々のペースで開発・改修できる
• 可視性（Visibility）：リクエストが自己記述的であるため、途中の中間サーバー（プロキシ、CDN、ロードバランサー）がリクエスト内容を理解し、キャッシュや最適化を行いやすい
• 単純さと学習しやすさ：HTTPの標準的な意味論（GET/POST/PUT/DELETE等）をそのまま利用するため、新しいプロトコルを覚える必要がない

デメリット

• 統一インターフェースゆえの非効率：リソース単位で固定的なレスポンス形式になるため、オーバーフェッチ/アンダーフェッチが発生しやすい
• ステートレス性のオーバーヘッド：セッションを保持しないため、毎回のリクエストに認証情報などのコンテキストを含める必要があり、通信量が増える場合がある
• HATEOASの実装コスト：統一インターフェースの副制約であるHATEOASは理論的には有用だが、実装が複雑でクライアント側の対応も必要なため、実務ではほとんど省略されている

具体例：Richardson成熟度モデル

RESTfulな設計がどこまで徹底されているかを測る指標として、Leonard Richardsonが提唱した「Richardson成熟度モデル」がよく引用されます。アーキテクチャスタイルとしてのREST準拠度を4段階で示す考え方です。

• レベル0：HTTPを単なるトンネルとして使い、単一のエンドポイントにXML-RPCやSOAPのようなメッセージを送る
• レベル1：URLでリソースを分割する（例: /users, /orders）が、HTTPメソッドは使い分けない
• レベル2：GET・POST・PUT・DELETEなどHTTPメソッドとステータスコードを適切に使い分ける（多くの実務APIはこのレベルにとどまる）
• レベル3：レスポンスにリンク情報を含めるHATEOASを実装し、クライアントがリンクをたどって次の操作を発見できる

REST・SOAP・RPCのアーキテクチャスタイル比較

REST登場以前から存在するSOAPや、内部通信で使われるRPCスタイルとの違いを整理します。

項目	REST	SOAP	RPCスタイル（gRPC等）
設計思想	リソース指向	メッセージング指向（手続き呼び出し）	手続き呼び出し（サービス定義ベース）
データ形式	任意（主にJSON）	XML固定	Protocol Buffers等のバイナリ
標準化の厳格さ	緩い（アーキテクチャスタイル）	厳格（WS-*仕様群）	IDL（.protoファイル等）で厳密に定義
主な用途	Web API全般	金融・決済など高信頼が求められるエンタープライズ連携	マイクロサービス間の高速な内部通信

関連技術と用語

• API - ソフトウェア間通信の基本概念
• GraphQL - 柔軟なクエリが可能なAPI技術
• gRPC - 高性能なRPCフレームワーク
• HTTP/2 - RESTの基盤プロトコルの進化版
• HTTP/3 - QUICベースの最新プロトコル

外部リンク

• Roy Fielding - REST（博士論文）
• OpenAPI Specification
• RESTful API Tutorial

この用語についてもっと詳しく

REST API設計や実装に関するご相談は、お気軽にお問い合わせください。