CRM を同期する、配送状況を取得する、2つの SaaS を連携する。こうした処理を支えているのが REST API です。利用者が直接意識する機会は少なくても、システム間のデータ連携や業務自動化に広く関わっています。
REST APIを評価するうえで最初に押さえたいのは、何をもって「RESTful」と呼ぶかについて、開発者の間でも解釈に差があることです。この言葉が幅広く使われるなか、ある Reddit のスレッドでは、「Roy Fielding の定義に照らして、本当に RESTful な API を一度でも作れた気がしない。」という開発者の声もありました。REST という概念は、UC Irvine での Roy Fielding による 2000年の博士論文 に端を発します。REST はプロトコルや製品ではなく、設計上の制約をまとめたアーキテクチャスタイルです。
Postman の 2025年版 API State レポート では、API 担当者の93%が REST を使用していると報告されています。一方、広く使われている「RESTful」という呼称と、Fielding が示した制約への準拠度は必ずしも一致しません。本記事では、REST API の6つの基本特性、設計時につまずきやすい点、自己診断に使える成熟度モデルを整理し、SOAP・GraphQL・gRPC といった選択肢との違いを解説します。
REST APIとは？（やさしい定義）
REST（Representational State Transfer）とは、ソフトウェア同士がネットワーク越しに通信する際の設計ルールをまとめたものです。
より正確には、REST はアーキテクチャスタイルであり、ステートレス性、キャッシュ可能性、統一インターフェースなどの制約を定義します。これらの制約が、クライアント（ブラウザ、モバイルアプリ、自動化ツールなど）とサーバー（データや処理を提供する側）のやり取りを方向づけます。REST はHTTP上で実装され、JSONを返すケースが一般的ですが、REST自体が特定のプロトコルやデータ形式を指定しているわけではありません。
RESTが定めるのは、個々のデータ内容ではなく、リソースの識別方法、リクエストに必要な情報、レスポンスの解釈方法など、システム間で共有する通信上の原則です。この原則がそろっていると、クライアントはAPIの動作を予測しやすくなります。
REST ではないもの： REST はインストールする製品ではなく、HTTP や SOAP のようなプロトコルでもありません。また、API を「RESTful」と呼んでいても、Fielding の元の制約に完全準拠しているとは限りません。実務では、リソース URL と HTTP メソッドを採用したAPIを広い意味でRESTfulと呼ぶ場合もあります。この呼称と厳密な準拠度の違いは、以降の各制約と成熟度モデルを使って整理できます。
REST APIの6つの特性を一覧で押さえる
詳細に入る前に、まずは早見表です。Fielding は、API が RESTful とみなされるために守るべき制約を6つ定義しました。うち5つは必須、1つは任意です。
| 制約 | 基本的な考え方 | 主な利点 | 具体例 |
|---|---|---|---|
| クライアント・サーバー | UIとデータ保存を分離する | フロントエンドとバックエンドを独立して進化できる | React SPAがREST APIを呼び出す |
| ステートレス | 各リクエストが必要な文脈をすべて持つ | 水平スケールがしやすく、セッション固定が不要 | 毎回のリクエストヘッダーに認証トークンを送る |
| キャッシュ可能 | レスポンスがキャッシュ可能かを明示する | レイテンシとサーバー負荷を削減 | GETレスポンスに Cache-Control: max-age=3600 を付ける |
| 統一インターフェース | リソース操作を標準化する | 予測しやすく、学習しやすいAPIになる | GET /users/42、DELETE /users/42 |
| レイヤードシステム | クライアントはサーバーに直接つないでいるか判別できない | CDN、ゲートウェイ、ロードバランサーを挟める | Client → CDN → API Gateway → App Server |
| コードオンデマンド（任意） | サーバーが実行可能コードを送ってクライアントを拡張できる | 必要に応じてクライアント機能を拡張できる | JavaScriptのウィジェット断片を返すAPI |
これらの制約が現実のシステムでどう噛み合うのかをつかむには、次のような階層型アーキテクチャを思い描いてみてください。
Client / Mobile App
↓
CDN / Edge Cache (e.g., Cloudflare)
↓
API Gateway (rate limiting, auth, CORS)
↓
Load Balancer
↓
Application Servers
↓
Database / Internal Services
クライアントが直接触れているのは、最前段の CDN 層だけです。その奥に何層あるのかを、クライアントは知りません。これがレイヤードシステムという制約の働きであり、セキュリティ・キャッシュ・スケーリングをクライアントに意識させずに実現できる理由でもあります。
以下で、各制約の役割を順に説明します。
REST APIの特性を1つずつ解説
クライアント・サーバー分離
Fielding がまず挙げた制約は、クライアント（ユーザーが触れる側）とサーバー（データを持ち、ロジックを動かす側）を分けることです。彼はこれを関心の分離と呼びました。
この分離が実務で有効なのは、画面とバックエンドを独立して変更しやすくなるためです。たとえばモバイルバンキングアプリでは、銀行が口座データベースや取引エンジンを変更しなくても、画面を全面的に作り直せます。Salesforce Marketing Cloud REST API は、コンタクト、キャンペーン、ジャーニー、プッシュ通知をリソースエンドポイントとして提供しています。独自ダッシュボード、モバイルアプリ、サードパーティ連携のいずれからでも、同じバックエンドを利用できます。
ビジネスチームにとっては、フロントエンドとバックエンドを同一のリリースサイクルに固定せず、API契約を基準に並行して開発できることが利点です。契約が安定していれば、各チームは担当領域をそれぞれの計画に沿って更新できます。
ステートレス性
ステートレス性とは、各リクエストを独立して処理できるようにする考え方です。クライアントからサーバーへの呼び出しには、その処理に必要な情報を含め、サーバーは前回のリクエストに保存されたセッション情報を前提にしません。
この設計では、ロードバランサーが各リクエストを利用可能なサーバーへ振り分けやすくなります。特定のサーバーだけがクライアントの状態を保持しないため、処理台数の追加や障害時の切り替えにも対応しやすくなります。これが水平スケーリングとの関係です。
技術的には、ステートレスな設計では sticky session への依存を避けます。ロードバランサーは次のリクエストを正常なサーバーへ振り分けられ、1台に障害が起きても別のサーバーで処理を継続しやすくなります。Fielding の論文ははっきりと、ステートレス性が可観測性（監視ツールが各リクエストを独立して把握できる）、信頼性（障害が共有セッション状態を壊さない）、拡張性（リクエスト間でサーバーがリソースを解放できる）を高めると述べています。
現実のシステムには、認証トークン、ショッピングカート、OAuth フローなどの状態があります。ステートレス性は「どこにも状態がない」という意味ではありません。サーバーのメモリにクライアント固有のセッション状態を保持し、後続リクエストがそのサーバーに依存する構成を避けることが要点です。必要な状態は、トークン、データベース、共有キャッシュなどで管理します。
キャッシュ可能性
キャッシュ可能性とは、レスポンスを後続の同等リクエストに再利用できるかを明示する制約です。再利用できるレスポンスは、クライアントやCDNなどの中間層に保存でき、サーバー負荷と応答時間の削減につながります。
HTTP では、Cache-Control、ETag、Last-Modified、Expires といったヘッダーを使い、レスポンスの有効期限や再検証の条件を伝えます。業務上は、データの更新頻度と機密性を踏まえ、再利用できる期間や保存を禁止する条件を決める必要があります。
性能への効果は、構成やキャッシュヒット率によって異なります。一般に、キャッシュはバックエンドへのリクエストを減らし、応答時間の改善に寄与する場合があります。Fielding の論文には、Web トラフィックが1994年の1日10万リクエストから、1999年には1日6億リクエストへ増加したという記録があり、その拡大を支えた要因のひとつとしてキャッシュが挙げられています。
キャッシュしやすい代表例： 商品カタログ、公開ブログ記事、国・通貨の一覧、API ドキュメント。
キャッシュしにくい代表例： 個人ダッシュボード、チェックアウトの合計金額、銀行残高、管理者レポート。
統一インターフェース
Fielding 自身が、REST を他のアーキテクチャスタイルから分かつ中心的な特徴と呼んだのが、この制約です。クライアントがリソースを操作する方法を標準化し、API を予測しやすくします。
この大枠の中に、4つの下位制約があります。
- リソース識別： すべてのリソースに安定した URI を与える。
/customers/123は顧客、/orders/456は注文です。 - 表現を介した操作： クライアントが扱うのは、サーバー内部のオブジェクトそのものではなく、リソースの表現（JSON、XML、HTML）です。
- 自己記述的メッセージ： リクエストとレスポンスには、メソッド、ステータスコード、コンテンツタイプ、エラー詳細など、中間層やクライアントが解釈できる十分なメタデータが含まれます。
- HATEOAS（Hypermedia as the Engine of Application State）： レスポンスに関連アクションやリソースへのリンクを添え、各エンドポイントを固定しなくても、クライアントが次の一手を見つけられるようにします。
HTTP メソッドと CRUD の対応は、統一インターフェースのなかでもっとも目に見える部分です。
| HTTPメソッド | CRUDの意味 | 安全 | 冪等 | 例 |
|---|---|---|---|---|
| GET | 取得 | はい | はい | GET /products/42 |
| POST | 作成 / アクション | いいえ | いいえ | POST /orders |
| PUT | リソース全体を置換 | いいえ | はい | PUT /users/42 |
| PATCH | 部分更新 | いいえ | 保証されない | PATCH /users/42 |
| DELETE | 削除 | いいえ | はい | DELETE /sessions/abc |
Google Cloud の HTTP ガイドライン では、GET は安全であるべきで、GET・PUT・DELETE は冪等であるべきだと明記されています。GitHub、Stripe、Spotify といった有名 API はこのパターンにかなり忠実で、ひとつ覚えれば別の API もすぐ読み解ける——その理由がここにあります。
レイヤードシステム
レイヤードシステムでは、クライアントが接続先の背後にある構成を把握する必要はありません。接続先がオリジンサーバー、CDN キャッシュ、API ゲートウェイ、ロードバランサーのいずれであっても、各コンポーネントは隣接する層とのインターフェースに従って動作します。
これによって、次のような構成を採用できます。
- Cloudflare のような CDN を API の前段に置き、レスポンスをキャッシュして高速化する
- API ゲートウェイ（AWS API Gateway、Kong、Apigee など）が認証、レート制限、クォータ管理を引き受ける
- ロードバランサーがステートレスなリクエストを複数のアプリサーバーへ振り分ける
Postman の 2025年レポート では、47%の組織 が AWS API Gateway を使い、26%が Azure のゲートウェイを使い、31%が複数のゲートウェイを併用していると報告されています。こうした構成は、認証、負荷分散、キャッシュなどの責務を分ける本番システムで利用されています。
層を増やすと、処理経路が長くなり、レイテンシが増える場合があります。一方、Fielding は、多くの実システムでは中間層の共有キャッシュによって、そのオーバーヘッドを補えると論じています。
コードオンデマンド（任意）
コードオンデマンドは、6つの制約のうち唯一の任意項目です。サーバーが JavaScript などの実行可能コードを送信し、必要に応じてクライアントの機能を拡張します。
一般的な例は、Web ページがサーバーから JavaScript を読み込んで機能を追加する構成です。一方、モバイルアプリ、バックエンドジョブ、自動化ツールが利用するJSON中心のREST APIでは、サーバーから受け取った任意コードを実行する必要がないため、採用される場面は限定的です。
そのため、日常的なAPI評価では、コードオンデマンドを任意制約として把握したうえで、対象システムに実行可能コードを配信する要件がある場合に検討すれば十分です。
REST準拠の程度と実務上の採用状況
実務では、「RESTful」と呼ばれるAPIでも、Fieldingが示したすべての制約を同じ程度に採用しているとは限りません。リソースURL、HTTPメソッド、ステータスコードを使うHTTP JSON APIを、広い意味でRESTfulと呼ぶケースもあります。r/softwarearchitecture の Reddit スレッドでは、Fielding 準拠の REST API を実際に作ったことはないという開発者の投稿があり、r/learnprogramming の別の議論でも「RESTful」の定義をめぐって意見が分かれていました。
2026年のある調査では、16人の REST API 専門家へのインタビューを通じて、ガイドラインは使いやすさの向上に役立つ一方、規則の多さや各組織への適用の難しさが障壁になると報告されています。
実務での採用傾向を制約ごとに整理すると、次のようになります。
| 制約 | 実務での採用状況 | 理由 |
|---|---|---|
| クライアント・サーバー | ✅ 多くのWeb APIで採用 | UIとデータ・処理を分離する一般的な構成 |
| ステートレス性 | ✅ 広く採用 | 水平スケーリングに有効で、標準的な実装 |
| 統一インターフェース（基本） | ✅ 一般的 | リソースURI + HTTP動詞がデフォルトのパターン |
| キャッシュ可能性 | ⚠️ 実装にばらつき | Cache-Control ヘッダーが十分に設定されない場合がある |
| レイヤードシステム | ⚠️ 構成上採用されることが多い | CDNやゲートウェイを使っていても、設計意図が明文化されない場合がある |
| HATEOAS | ❌ 採用は限定的 | 多くのクライアントはエンドポイントをハードコードしており、リンクベースの発見には追加設計が必要 |
| コードオンデマンド | ❌ 採用は限定的 | 定義上オプションで、JSON APIで必要になる場面が少ない |
多くのチームが HATEOAS を見送る理由： クライアント開発者は、実行時にリンクを動的にたどる方法より、OpenAPI ドキュメントやSDKを使う方法を選ぶことがあります。HATEOASを採用するには、安定したメディアタイプ、リンク関係、ワークフローの設計が必要です。その追加工数に対する効果を説明しにくいことが、採用を限定する要因になります。
API が Fielding の制約に100%準拠していなくても、実務で有用な場合はあります。重要なのは、省略した制約と、それに伴うキャッシュ性、発見可能性、拡張性などのトレードオフを把握したうえで設計・統合を判断することです。
Richardson成熟度モデルによるREST準拠度の評価
RESTへの準拠を二者択一で判断するのではなく、段階的に評価する方法としてRichardson成熟度モデルがあります。Leonard Richardson が提唱し、Martin Fowler が解説した このモデルは、REST の採用度を4段階に分けます。
| レベル | 名称 | 説明 | 実例 |
|---|---|---|---|
| 0 | POXの沼 | 単一URI、単一HTTP動詞（通常POST） | レガシーなSOAP over HTTPエンドポイント、POST /api に { "action": "getUser" } を送る形 |
| 1 | リソース | 複数URI（リソースごとに1つ）だが、依然としてPOST中心 | POST /users/123/getProfile、POST /orders/456/cancel |
| 2 | HTTP動詞 | GET、POST、PUT、DELETEと適切なステータスコードを正しく使う | 現在の多くの本番「REST」API |
| 3 | ハイパーメディア（HATEOAS） | レスポンスに関連アクションやリソースへのリンクを含む | Spring Data REST、HALベースのAPI。実際の公開APIでは非常に少ない |
実務で見かけるAPIには、レベル2に相当するものが多くあります。リソース、HTTPメソッド、ステータスコードを使い分ける段階で、相互運用性が高く、対応ツールも豊富です。レベル3ではHATEOASを導入し、レスポンスから次の操作を発見できるようにしますが、公開APIでの採用は限定的です。
APIの現在地は、次の観点で評価できます。
- すべてを単一のエンドポイントで処理していませんか。（レベル0）
- 業務オブジェクトごとに個別の URI がありますか。（レベル1以上）
- HTTP メソッドとステータスコードを正しく使っていますか。（レベル2）
- 外部ドキュメントに頼らず、レスポンスだけで次にできることが分かりますか。（レベル3）
私自身、このモデルは「REST かどうか」という議論を整理する際に役立つと考えています。二者択一ではなく、現在の設計と次に改善する点を段階で把握できるためです。
よくあるREST APIのミスと、その避け方
私はこれまで、サードパーティAPIの統合作業に多くの時間を費やしてきました。その経験や開発者フォーラムで繰り返し挙がる問題をもとに、代表的なアンチパターンを整理します。いずれも、RESTの制約やHTTPの意味を十分に活かせなくなる設計です。
| アンチパターン | なぜRESTを壊すのか | 代わりにどうするか |
|---|---|---|
エラー本文付きのHTTP 200（{ "error": "Invalid username" }） | 自己記述的メッセージに反し、クライアントがステータスコードを信用できない | 適切な4xx/5xxコード + 構造化されたエラー本文を使う（例：application/problem+json） |
| すべてPOSTで処理する | 統一インターフェースを無視し、安全性/冪等性の意味を失う | CRUDを GET/POST/PUT(PATCH)/DELETE に対応させる |
Cache-Control ヘッダーがない | キャッシュ可能性を活用できない | 明示的なキャッシュ指示を設定する。機密データには no-store でもよい |
| あいまいなエラーレスポンス（「409 error」） | 人間にも機械にも、何が悪かったのかわからない | エラー種別、人間向けメッセージ、ドキュメントへのリンクを含める |
| HTTPSを強制しない | BearerトークンやAPIキーが平文で流れる | すべてTLSを強制する。Google APIsはHTTPSのみをデフォルトにしている |
| リクエスト本文でバージョン管理する | リソース識別を壊し、ゲートウェイやキャッシュが正しく振り分けられない | URIパスでのバージョン管理（/v1/）か、Acceptヘッダーによるバージョン管理を使う |
Zalando の RESTful API ガイドライン では、公式の HTTP ステータスコードの使用が必須とされ、エラー応答には Problem JSON が推奨されています。Adidas の API ガイドライン では、Problem Detail は4xx/5xxにのみ使い、2xxと混在させない方針が示されています。これらは、大規模なAPI運用でエラー処理を一貫させるための実務的な基準です。
r/learnprogramming の Reddit スレッドには、エラー時にもHTTP 200を返してよいかという質問が投稿されていました。2026年時点でも同様の疑問が見られることから、ステータスコードとレスポンス本文の役割を設計段階で共有する必要があります。
REST vs SOAP vs GraphQL vs gRPC：REST APIの特性を比較する
RESTと代替手段を同じ観点で比較すると、それぞれの設計目的と適用条件を整理しやすくなります。
| 観点 | REST | SOAP | GraphQL | gRPC |
|---|---|---|---|---|
| プロトコル / 伝送 | アーキテクチャスタイル、通常はHTTP | XMLベースのメッセージングプロトコル、HTTP、SMTPなど | クエリ言語 / ランタイム、通常はHTTP上 | HTTP/2上のRPCフレームワーク |
| データ形式 | 通常はJSON、XML/HTMLも可 | XMLのみ（WSDL契約） | クエリ形状に一致するJSON | Protocol Buffers（バイナリ） |
| キャッシュ | HTTPキャッシュを利用しやすい（設計次第） | メッセージ設計や中間層によって異なる | 標準的なHTTPキャッシュには追加設計が必要 | HTTPキャッシュを前提としない |
| リアルタイム対応 | 標準機能ではない（ポーリング / webhookなどで対応） | 仕様やメッセージング基盤によって対応 | Subscriptionsで対応可能 | ストリーミングに対応 |
| 学習コスト | 低〜中 | 高 | 中 | 中〜高 |
| 向いている用途 | 公開API、CRUD、Web/モバイル連携 | エンタープライズ / レガシー、厳格な契約、コンプライアンス | 複雑なクエリ、柔軟なフロントエンド、モバイルアプリ | マイクロサービス間、高性能な内部通信 |
Postman による API アーキテクチャスタイルの比較 では、互換性、データ形状、操作、利用者向けツールを基準に選ぶことが勧められています。
用途ごとの選択基準：
- REST は、広い互換性、標準的なCRUD操作、HTTPキャッシュを重視する公開APIやWeb／モバイル連携の候補になります。
- SOAP は、厳格な契約、WS-Security要件、既存のレガシー連携を維持する必要があるエンタープライズ環境で選択肢になります。
- GraphQL は、フロントエンド側で取得フィールドを柔軟に指定し、入れ子の深いデータを扱う場合に向いています。
- gRPC は、低レイテンシ、バイナリシリアライズ、ストリーミングを重視し、ブラウザ互換性が主要要件ではない内部マイクロサービス通信に向いています。
REST風のAPIの例として、Thunderbit の Open API では、POSTエンドポイントの/distillと/extract、JSONのリクエスト／レスポンスボディ、Bearerトークン認証、標準HTTPステータスコード（400、401、402、408、422、429、500、502、503、504）を確認できます。HATEOASを備えたAPIではありません。Richardson成熟度モデル上の厳密な位置づけは、リソース設計とHTTPメソッドの使い分けを含めて評価する必要がありますが、ビジネスチームや開発者が連携に必要な情報を扱える実用的なAPIです。
REST APIの特性がビジネスチームにとって重要な理由
営業、オペレーション、Eコマースなど、APIのコードを直接書かないチームでも、ベンダーを選定し、ツールを接続し、自動化ワークフローを運用しています。REST APIの設計品質は、連携の安定性、例外処理の量、障害時の原因特定に影響します。
ツール連携： CRM とマーケティング自動化プラットフォームを同期するとき、REST API の設計次第で、その同期は安定にも脆弱にもなります。Salesforce Marketing Cloud REST API は、コンタクト、キャンペーン、ジャーニー、プッシュ通知を予測しやすいリソースエンドポイントで扱います。これらがRESTの慣習に従っていれば、RevOpsチームは独自の例外処理を増やさずに自動化しやすくなります。
Eコマース運用： Shopify のフルフィルメント REST リソース は、フルフィルメント注文、追跡番号、配送状態を扱います。配送アプリやフルフィルメントツールは、この層に依存しています。正しいステータスコード、キャッシュ可能なカタログデータ、明確なエラーメッセージが提供されていれば、物流連携を安定して運用しやすくなります。不明確な場合は、障害時の切り分けや復旧に時間がかかります。
ベンダー評価： 6つの制約を知っていれば、それがそのまま実務のチェックリストになります。
- API は標準のステータスコードを使っていますか、それとも失敗まで200 OKに見えますか。
- エラーは、自動化ツールが復旧できるほど具体的ですか。
- レート制限、ページネーション、認証について、明確なドキュメントがありますか。
- よく使うレスポンスをキャッシュして、負荷を減らせますか。
データ抽出と自動化： Thunderbit のようなツールは、REST ベースのアーキテクチャを使い、ビジネスユーザーが Web サイト、PDF、画像から構造化データを取り出し、Google Sheets、Airtable、Notion、Excel へ出力できるようにしています。Thunderbit の AI Web Scraper Chrome 拡張機能 は、2クリックの UI の裏で複雑な処理を引き受けます。その処理を支えるステートレスなリクエスト、JSONレスポンス、標準エラーは、外部ツールとの連携方法を予測しやすくする要素です。
Postman の2025年レポートでは、AI エージェントを前提に API を設計している開発者はわずか 24% で、51%は AI エージェントからの不正または過剰な API 呼び出しを懸念していました。AIを使った自動化が広がるなか、予測可能なRESTパターン、最小権限のAPIキー、レート制限は、開発上の設計事項だけでなく、運用リスクを管理するための条件にもなります。
Thunderbitがビジネスユーザー向けにREST原則をどう活かしているか
私たちは Thunderbit を、ビジネスユーザーがREST仕様を意識しなくてもデータ抽出を進められることを前提に設計しました。その操作を支える仕組みには、本記事で紹介したRESTの特性と共通する考え方があります。
具体的な操作の流れは次のとおりです。
- Chrome Web Store から拡張機能をインストールし、データを取りたい Web サイト、PDF、画像を開きます。
- 「AI Suggest Fields」をクリックすると、Thunderbit の AI がページを読み取り、商品名、価格、メールアドレスなど、ページ上で抽出候補となる項目を列として提案します。
- 必要に応じて列を調整してから、「Scrape」をクリックします。Thunderbitはページネーション、サブページ、動的コンテンツの取得に対応する設計ですが、対象ページの構造によって抽出結果は異なります。
- データをエクスポートします。Google Sheets、Airtable、Notion、CSV、Excelへの出力に対応しています。無料利用の範囲や条件は、現在のプラン内容に基づいて判断する必要があります。
開発者や自動化ワークフロー向けには、Thunderbit の Open API が、/distill（Markdown のクリーン抽出）と /extract（構造化データ抽出）を、JSON ボディと標準 HTTP エラーコードを持つREST風のPOSTエンドポイントとして公開しています。これらは、リクエストとレスポンスの形式やエラー処理を予測しやすくするためのHTTPの慣習を採用しています。Richardson成熟度モデルでの厳密な評価には、リソース設計とHTTPメソッドの使い分けを含む確認が必要です。
Web スクレイピングやデータ抽出をもっと深く知りたい方には、AIウェブスクレイピング、コードなしでのWebスクレイピング、Webスクレイピングとは何か についての詳しいガイドも用意しています。
押さえておきたいポイント
- REST はプロトコルではなく、アーキテクチャスタイルです。 API 設計を導く6つの制約——クライアント・サーバー、ステートレス、キャッシュ可能、統一インターフェース、レイヤードシステム、そして任意のコードオンデマンド——を定義します。
- 「RESTful」と呼ばれる API でも、厳密な制約をすべて満たしているとは限りません。 Richardson レベル2（リソース + HTTP 動詞 + ステータスコード）に相当する実装が多く、HATEOAS とコードオンデマンドの採用は限定的です。
- Richardson 成熟度モデルは、APIの現在地を段階的に評価するために使えます。 「REST か否か」という二択ではなく、レベル0〜3で採用状況と改善点を整理できます。
- エラーに200 OKを返す、すべてをPOSTで処理する、キャッシュヘッダーを設定しないといった設計は、連携時の誤判定や不要な負荷につながります。 各制約を基準にすると、アンチパターンを特定しやすくなります。
- REST、SOAP、GraphQL、gRPCは、要件に応じて選び分けます。 REST は公開 API と CRUD 連携、GraphQL は複雑なフロントエンド、gRPC は内部マイクロサービス、SOAP は厳格な契約や既存のエンタープライズ連携が必要な場合の候補です。
- ビジネスチームにとっても、REST の特性はベンダー評価や自動化設計の判断基準になります。 Thunderbit のようなツールでは、RESTの原則を利用者から見えない処理に活かし、技術的な専門知識がなくてもデータ抽出を進めやすくしています。
よくある質問
REST APIの6つの特性とは何ですか？
REST の6つの制約は、(1) クライアント・サーバー分離、(2) ステートレス性、(3) キャッシュ可能性、(4) 統一インターフェース、(5) レイヤードシステム、(6) コードオンデマンド（任意）です。最初の5つは、Fielding の元の定義では、API が RESTful とみなされるための必須条件です。
RESTとRESTfulの違いは何ですか？
REST は、Roy Fielding が定義した設計制約のまとまりであるアーキテクチャスタイルです。「RESTful」は、その制約に従う API を指します。実際には、「RESTful」と呼ばれる API の多くは部分的にしか準拠しておらず、たいていはリソース、HTTP メソッド、ステータスコードは使っていても、HATEOAS やコードオンデマンドは省かれています。
すべてのREST APIは、すべてのREST制約に従っていますか？
いいえ。現実の本番 API の多くは、クライアント・サーバー分離、ステートレス性、基本的な統一インターフェース（リソース + HTTP 動詞）には従っています。キャッシュ可能性とレイヤードシステムの設計は、実装にばらつきがあります。HATEOAS はまれで、JSON API でコードオンデマンドが使われることはほぼありません。
RESTとGraphQLの違いは何ですか？
REST は、標準の HTTP メソッド（GET、POST、PUT、DELETE）を使い、複数のエンドポイントでリソースを公開します。GraphQL は通常ひとつのエンドポイントを使い、欲しいフィールドをクライアントがクエリで正確に指定します。REST は HTTP キャッシュとの相性がより良く、GraphQL は複雑で入れ子の多いデータ要件に柔軟で、過剰取得を減らせます。
HATEOASとは何ですか？実際に使っている人はいますか？
HATEOAS（Hypermedia as the Engine of Application State）とは、API レスポンスに次に使える操作へのリンクを含めることで、各エンドポイントをハードコードせずに API をたどれるようにする考え方です。Fielding が描いた REST 像では中心的な要素（Richardson レベル3）ですが、実際にこれを実装している公開 API はごくわずかです。多くのチームはレベル2で止まり、代わりにドキュメントや SDK に頼っています。
AIウェブスクレイピングでThunderbitを試す Get Started Free
さらに詳しく
