REST API

この用語をシェア

概要

REST API（読み方: レストエーピーアイ、正式名称: RESTful API）とは、「REST」（Representational State Transfer、日本語訳: 表現状態転送）と呼ばれる設計原則に沿って構築されたWeb APIの総称です。RESTは特定の企業が策定した規格や製品名ではなく、HTTP/1.1の仕様策定にも携わった計算機科学者ロイ・フィールディング（Roy Fielding）氏が2000年の博士論文の中で提唱したアーキテクチャスタイル（設計思想）を指します。

一言でまとめると、REST APIは「URL（URI）で操作対象のリソースを一意に指定し、HTTPメソッド（GET・POST・PUT・PATCH・DELETEなど）でそのリソースに対する操作の種類を表現する、ステートレスなWeb APIの設計様式」です。英語表記は "REST API" または "RESTful API"、日本語では「レストAPI」とカタカナ表記されることもあります。現在「Web API」と呼ばれるものの多くはこのREST的な考え方を土台にしており、ECサイトの商品情報取得、SNSアプリのタイムライン取得、決済サービス連携、社内システム間のデータ連携など、インターネット上のサービス連携の大半を支えています。

なお「RESTに準拠している」ことと「Web APIである」ことはイコールではありません。厳密には後述する6つの制約条件をすべて満たして初めて「RESTfulである」と言えますが、実務上はHTTPメソッドとJSONを使ったAPI全般を緩やかに「REST API」と呼ぶ慣習が広く定着しています。この用語集ページでは、学術的な定義と実務での使われ方の両方を押さえて解説します。

補足として、フィールディング氏がRESTを提唱した2000年前後は、SOAPやCORBAといった仕様が重厚で複雑な分散システム間通信の主流でした。RESTはこうした重量級の規格に対するシンプルな代替案として広まり、2000年代後半から2010年代にかけてTwitter API・Google Maps APIなどが相次いでREST形式を採用したことで、Web業界のデファクトスタンダードとしての地位を確立しました。データ形式についても、当初はXMLでのレスポンスも多く見られましたが、現在では軽量で扱いやすいJSONが主流です。

仕組み・詳細解説

1. RESTを構成する6つの制約条件

フィールディング氏の論文では、RESTを名乗るアーキテクチャは次の制約を満たすべきとされています。クライアント/サーバー分離（画面とデータ処理の責務を分ける）、ステートレス性（各リクエストにサーバーが処理に必要な情報をすべて含め、サーバー側にセッション状態を持たない）、キャッシュ可能性（レスポンスをキャッシュ可能かどうか明示する）、統一インターフェース（URI・HTTPメソッド・メディアタイプという共通の語彙で操作を表現する）、階層化システム（クライアントはロードバランサーやゲートウェイの存在を意識しなくてよい）、そしてオプションのコードオンデマンド（必要に応じてクライアントに実行可能なコードを送る、あまり使われない）の6つです。実務では最初の4つ（クライアント/サーバー分離・ステートレス・キャッシュ可能・統一インターフェース）が特に重視されます。

2. リソース指向のURI設計

REST APIの設計で最も重視されるのが「リソース」という考え方です。操作の主語になるのは常に名詞（データの塊）であり、動詞は含めません。例えば「ユーザー一覧を取得する」機能のURIは /getUsers ではなく /users とし、「操作の種類」はURIではなくHTTPメソッド側で表現します。階層関係があるリソースはパスのネストで表現しますが、実務では2〜3階層程度に留めるのが定石です（例: /users/123/orders はよいが、/users/123/orders/456/items/789/reviews のように深くなりすぎると可読性・保守性が落ちます）。一覧取得時の絞り込みや並び替えはクエリパラメータ（例: /products?category=book&sort=price_asc）で表現するのが一般的です。

3. HTTPメソッドとCRUD・ステータスコードの対応

REST APIはデータベース操作の基本であるCRUD（Create・Read・Update・Delete）をHTTPメソッドに対応させます。対応関係は下表の通りです。

エラー時は4xx台（クライアント側の問題。400 Bad Request、401 Unauthorized、403 Forbidden、404 Not Found、409 Conflict、422 Unprocessable Entityなど）、5xx台（サーバー側の問題。500 Internal Server Error、503 Service Unavailableなど）を適切に返すことが、良質なREST APIの必須条件です。ステータスコードだけで大まかな成否を伝え、詳細な理由はレスポンスボディのJSONに含めるのが一般的な設計です。

設計上もう一つ重要な概念が「冪等性（べきとうせい、idempotency）」です。これは「同じリクエストを何度送っても結果が変わらない」性質のことで、GET・PUT・DELETEは冪等であるべきとされます（例: 同じリソースを2回DELETEしても、1回目で削除済み・2回目は404になるだけで状態としては変わらない）。一方POSTは呼び出すたびに新しいリソースが作られるため冪等ではありません。通信が不安定な環境でクライアントがリクエストを再送する場合など、冪等性の有無は障害設計に直結する重要な観点です。

4. ステートレス通信とキャッシュ制御

REST APIの大きな特徴が「ステートレス」であることです。サーバーは前回のリクエストの内容を記憶せず、認証トークン（例: JWTやAPIキー）や必要なパラメータを毎回のリクエストに含める必要があります。これによりサーバーを水平スケール（台数を増やして負荷分散）しやすくなり、どのサーバーがリクエストを受けても同じ結果を返せるようになります。一方で、頻繁に変わらないデータ（マスタ情報や画像など）に対しては、HTTPの標準的なキャッシュ機構（Cache-Control、ETag、Last-Modifiedヘッダーなど）を活用することで、サーバー負荷とレスポンス時間を大きく削減できます。

具体例・ユースケース

実際のリクエスト・レスポンスのイメージを示します。まずはリソースを取得するGETの例です。

GET /api/v1/orders/98765 HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Accept: application/json

--- レスポンス ---
HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 98765,
  "status": "shipped",
  "product_name": "ワイヤレスキーボード",
  "quantity": 2,
  "total_price": 4980,
  "created_at": "2026-06-20T09:30:00+09:00"
}

次に新規リソースを作成するPOSTの例です。作成に成功した場合は、新しく作られたリソースの場所を示す Location ヘッダーとともに 201 Created を返すのがベストプラクティスです。

POST /api/v1/orders HTTP/1.1
Host: api.example.com
Content-Type: application/json

{
  "product_id": 5821,
  "quantity": 2
}

--- レスポンス ---
HTTP/1.1 201 Created
Location: /api/v1/orders/98765
Content-Type: application/json

{
  "id": 98765,
  "status": "pending",
  "total_price": 4980
}

REST APIが実務で使われる代表的な場面としては、次のようなものが挙げられます。

• フロントエンドとバックエンドの分離: React・Vue.jsなどのSPA（シングルページアプリケーション）が、バックエンドのREST APIからJSONデータを取得して画面を描画する構成。
• モバイルアプリのバックエンド: iOS/Androidアプリが同一のREST APIサーバーと通信し、Web版アプリと処理ロジックを共通化する構成。
• マイクロサービス間連携: 注文サービス・在庫サービス・決済サービスなど、機能ごとに分割されたサービス同士がREST APIで疎結合に連携する構成。
• 外部サービスとの連携（サードパーティAPI）: 決済サービスや地図サービス、チャットツールなど、外部が公開するREST APIを自社システムに組み込む構成。
• IoTデバイスとの通信: センサーやスマート家電が定期的にREST API経由でクラウドにデータを送信する構成（ただしリアルタイム性が求められる場合はWebSocketやMQTTが選ばれることも多い）。

メリット・デメリット

混同されやすい用語・類似技術との違い

「REST API」は他のAPI設計スタイルや通信方式と混同されがちです。それぞれの違いを整理します。

実務での設計ポイント

実際にREST APIを設計・運用する際に押さえておきたい実務ポイントを整理します。

• バージョニング: /api/v1/...のようにURLパスにバージョンを含める方式が最も分かりやすく広く使われています。ヘッダーで指定する方式もありますが、ドキュメント化のしやすさからパス方式が実務では定石です。
• ページネーション: 一覧取得APIでは、?page=2&per_page=20のようなオフセット方式か、?cursor=xxxxのようなカーソル方式でページングを行い、全件を一度に返さない設計にします。大規模データではカーソル方式のほうが性能劣化が起きにくいとされています。
• 認証・認可: 本番運用ではOAuth 2.0（第三者アプリへの権限委譲）やJWT（トークンにユーザー情報や有効期限を含める）を組み合わせるのが一般的です。単純なAPIキーのみの認証は、漏えい時のリスクが高いため外部公開APIでは推奨されません。
• 通信の暗号化: 認証情報やユーザーデータをやり取りする以上、HTTPSによるTLS暗号化は必須です。平文のHTTPで本番運用することは重大なセキュリティリスクになります。
• レート制限（スロットリング）: 特定クライアントからの過剰なリクエストによるサーバー過負荷や不正利用を防ぐため、API Gatewayなどで一定時間あたりのリクエスト数に上限を設けます。制限に達した場合は429 Too Many Requestsを返すのが慣例です。
• エラーレスポンスの統一: すべてのエラーで{ "error": { "code": "...", "message": "..." } }のような共通フォーマットを使うと、クライアント側の実装が大幅に簡素化されます。
• 入力値のバリデーションとCORS設定: 想定外のリクエストボディを弾くバリデーションに加え、ブラウザから別オリジンのAPIを呼ぶ場合はCORS（Cross-Origin Resource Sharing）の設定を適切に行う必要があります。
• ドキュメント化とテスト: OpenAPI（旧Swagger）仕様でAPI定義を記述しておくと、ドキュメントの自動生成、モックサーバーの作成、SDKの自動生成が可能になります。動作確認にはPostmanやcurl、Insomniaといったツールがよく使われます。

2025〜2026年の最新動向

2025年以降、REST API周辺で特に目立つ動きは、生成AI・LLM関連APIの急増です。チャットボットやAIエージェントがバックエンドの様々な機能をREST API経由で呼び出す構成が一般化し、API Gatewayによるレート制限やコスト管理、利用量に応じた課金設計の重要性が一段と増しています。あわせてOpenAPI 3.1（JSON Schemaとの互換性が強化されたバージョン）準拠のAPI設計・自動ドキュメント生成が実務で標準的な選択肢になりつつあります。

設計スタイルの面では、単純な一覧・詳細取得はRESTで、複数リソースを横断的に取得する画面はGraphQLで、といった「REST一辺倒ではなく用途に応じて使い分ける」考え方が定着してきました。またマイクロサービス間の内部通信では高速性を重視してgRPCを採用し、外部公開用のAPIはREST（またはREST＋GraphQL）で提供するというハイブリッド構成も珍しくありません。加えてHTTP/2・HTTP/3の普及により、多数の小さなリクエストを発行するREST APIの通信効率自体も改善が進んでいます。セキュリティ面では、APIエンドポイントを狙った自動化された不正アクセスの増加を受け、OWASP API Security Top 10を参照した設計レビューを行う組織が増えている点も実務上の傾向として押さえておきたいところです。

よくある質問（FAQ）

関連用語

外部リンク・参考資料

• RESTful API設計ガイド（restfulapi.net）
• OpenAPI Specification（swagger.io）
• REST の用語解説（MDN Web Docs）
• Roy Fielding氏の博士論文（REST提唱の原典、英語）

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

REST APIに関するご質問や、システム導入のご相談など、お気軽にお問い合わせください。