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仕様からサーバー/クライアントコードの自動生成ツールも成熟し、開発効率が向上しています。
関連技術と用語
- API - ソフトウェア間通信の基本概念
- GraphQL - 柔軟なクエリが可能なAPI技術
- gRPC - 高性能なRPCフレームワーク
- HTTP/2 - RESTの基盤プロトコルの進化版
- HTTP/3 - QUICベースの最新プロトコル
外部リンク
よくある質問（FAQ）
Q. RESTとは何ですか？
REST（Representational State Transfer）は、2000年にRoy Fieldingが提唱したWebサービスのアーキテクチャスタイルです。HTTPプロトコルを活用し、リソースをURLで表現してHTTPメソッドで操作するシンプルな設計原則です。
Q. RESTful APIの6つの制約とは？
クライアント・サーバー分離、ステートレス性、キャッシュ可能性、統一インターフェース、階層化システム、コードオンデマンド（オプション）の6つです。
Q. REST APIとGraphQLはどちらを選ぶべき？
シンプルなCRUD操作やキャッシュが重要な場合はREST、複雑なデータ関係を持ちクライアントが柔軟にデータを取得したい場合はGraphQLが適しています。
Q. REST APIのステータスコードの使い分けは？
200（成功）、201（作成完了）、204（コンテンツなし）、400（不正リクエスト）、401（認証なし）、403（権限なし）、404（未検出）、500（サーバーエラー）が主に使われます。