REST API とは（レスト・エーピーアイ）URLでデータを指定し、HTTPの GET や POST で頼む形のAPI。GraphQL・Graph API との違いと、実際に呼んだ結果つき【2026年10月版】

2026年10月8日・日本時間時点の情報です。 REST API（レスト・エーピーアイ）とは、ウェブと同じ HTTP と URL を使い、データを URL で指定して、GET や POST といった動詞で「読む」「作る」「置き換える」「消す」を頼む形のAPIです。MDN Web Docs（Mozilla が運営する開発者向けの資料）は、初心者は REST API を「標準的なウェブライブラリーやツールを使って呼び出すことができる HTTP サービス」と思えばよいと書いています。REST は設計の考え方の名前で、それ自体に料金はなく、使えるか・いくらかは各APIの提供元の条件で決まります。

3行まとめ

• REST は Representational State Transfer の略。Roy Fielding が2000年の博士論文で示した設計上の制約の集まりで、MDN は、HTTP API が俗に RESTful API などと呼ばれても REST の制約をすべて守るとは限らないと注意している（2026年10月8日取得）。
• 筆者は2026年10月8日4時54分、鍵なしの公開APIに GET・POST・PUT・DELETE を送り、200・201・404 が返ることを確かめた。同じ日に公開 GraphQL サーバーへ問い合わせ、頼んだ項目だけが返る様子も見た。
• GraphQL は REST と並ぶ別の設計で、Graph API（Meta・Microsoft）は製品名。OpenAI・Claude・Gemini の公式資料はどれも自社のAPIに REST の語を使っている。

APIそのものの意味（天気アプリの例、APIキー、ChatGPT のアプリとAPIの違い）はAPIとはに、アプリ同士をつなぐ使い方（Zapier・n8n・Webhook）はAPI連携とはに分けました。この記事は「REST」の部分、つまり呼び方の約束と、GraphQL・Graph API との区別を扱います。

REST API とは何か。MDN・AWS・IBM は同じように説明しているのか

MDN の用語集は、REST を次のように書いています。

REST (Representational State Transfer) は、効率的で信頼性が高く、スケーラブルな分散システムを実現するためのソフトウェアアーキテクチャ設計上の一連の制約条件のことです。

「アーキテクチャ設計上の制約条件」とは、システムを作るときに守る決まりごとの集まり、という意味です。MDN は続けて、日常での使われ方に注意を促しています。

一般的に HTTP API は、俗に RESTful API、RESTful サービス、REST サービスなどと呼ばれることがありますが、必ずしも REST のすべての制約に準拠しているわけではありません。初心者の方は、REST API とは、標準的なウェブライブラリーやツールを使って呼び出すことができる HTTP サービスのことだと思ってください。

AWS の日本語ページは、REST を「API の動作に条件を課すソフトウェアアーキテクチャ」と説明し、こう書いています。

REST アーキテクチャスタイルに従う API は、REST API と呼ばれます。

さらに、REST API と RESTful API（レストフル・エーピーアイ）は同じ意味で使える、とも書いています。IBM の日本語ページは、REST は2000年に Roy Fielding 博士が博士論文の中で初めて定義したと書いています。

Fielding の博士論文（カリフォルニア大学アーバイン校、2000年）の要旨は、REST の狙いを次のように書いています。

REST emphasizes scalability of component interactions, generality of interfaces, independent deployment of components, and intermediary components to reduce interaction latency, enforce security, and encapsulate legacy systems.

（訳）REST は、部品どうしのやり取りの拡張性（規模を大きくできること）、インターフェースの汎用性、部品を別々に配備できること、そして、待ち時間を減らし、安全性を保ち、古いシステムを包み込むための中間の部品を重視する。

同じ論文の第6章は、REST の初版が1994年10月から1995年8月にかけて、HTTP/1.0 の仕様と HTTP/1.1 の最初の案を書く中でウェブの考え方を伝えるために作られ、もとは「HTTP object model」と呼ばれていたと書いています。

ここまでをまとめると、「REST」という語には2つの使われ方があります。

筆者が REST API を実際に呼ぶと、何が返ってきたのか

鍵なしで使える公開APIを呼びました。2026年10月8日4時54分、手元の Mac から curl（コマンドでHTTPを送るツール）を使っています。

JSONPlaceholder は、ダミーのデータを返す練習用の公開APIです。公式ページは POST について「The resource is not really created on the server, but the response is faked as if.」（リソースは実際にはサーバー上に作られず、作られたかのように応答が偽装される）と書いています。つまり上の POST・PUT・DELETE は、成功したように見える応答を受け取っただけで、実際のデータは変わっていません。それでも、「動詞と URL を送ると、ステータスコードと JSON が返る」という REST API の基本の形は、そのまま確かめられます。

ブラウザでも同じことができます。1分後の4時55分に、Open-Meteo の同じ URL をヘッドレスのブラウザ（画面を出さずに動くブラウザ）で開くと、ページ全体が JSON の文字列になりました。ブラウザのアドレスバーに URL を入れる操作は GET なので、鍵のいらない GET の REST API は、ブラウザだけで試せます。Meta の Graph API の概要ページも、ブラウザで URL を開くことは curl で GET を送るのと同じ、と説明しています。

比較用に呼ぼうとした別の公開API（国の情報を返すもの・URL に v3.1 を含む）は、データの代わりに「This API version has been deprecated.」（この版は非推奨になった）と新しい版への移行を求めるメッセージを返しました。URL に版が入った API では、版が変わると古い呼び出しが使えなくなることがある、という実例です。

URL・メソッド・ステータスコードは、それぞれ何を決めているのか

AWS の日本語ページは、REST API の要求に含まれる要素として、リソース（画像、動画、テキスト、数字など）を指す URL（リクエストエンドポイントとも呼ばれる）、リソースに何をするかを伝える HTTP メソッド、形式などの付帯情報を運ぶ HTTP ヘッダー、POST や PUT で送る中身、サーバーに詳細を伝えるパラメータ（URL のパスやクエリ、Cookie）を挙げています。

メソッドの意味は、MDN の「HTTP リクエストメソッド」で確かめました。

「べき等」とは、同じ要求を何回送っても結果が同じになる性質です。AWS のページも、同じ POST を複数回送ると同じリソースを複数回作る副作用があり、同じ PUT は何回送っても同じ結果になる、と書いています。

ステータスコードは、結果を3桁の数字で伝えます。AWS は「2XX コードは成功を示しますが、4XX および 5XX コードはエラーを示します。3XX コードは URL リダイレクトを示します」と書いています。筆者が上で受け取った 200 は成功、201 は作成成功、404 は見つからない、です。MDN は、401 Unauthorized について、HTTP 標準の名前は「unauthorized」でも意味は「unauthenticated」（未認証）であり、リクエストされたレスポンスを得るには認証が必要だと書いています。429 Too Many Requests は一定の時間内に大量のリクエストを送った（レート制限）時のコードです。

「REST らしい」とは、どんな約束を守ることか

IBM の日本語ページは「REST 設計原則」として、統一されたインターフェース（同じリソースへの要求は送信元に関係なく同じに見える）、クライアントとサーバーの分離、ステートレス、キャッシュ性、階層化されたシステム、コード・オンデマンド（任意）の6つを挙げています。AWS は、このうちクライアントとサーバーの分離を除く5つを「原則の一部」として挙げています。

このうち「ステートレス」について、IBM は、それぞれの要求に処理に必要な情報がすべて含まれ、サーバー側のセッションを必要としない、と書いています。AIのAPIも、OpenAI と Claude の資料では要求ごとに鍵を Authorization ヘッダーに付けます（これをステートレスと結びつけるのは筆者の整理で、公式の説明文ではありません）。ただし、OpenAI の API Reference には会話を作成・取得する Conversations が、Claude の API 概要には「stateful agent sessions」（状態を持つエージェントのセッション）を動かす Sessions API もあり、AIのAPIがすべてステートレスなわけではありません。

ChatGPT・Claude・Gemini の API は REST API なのか

3社の公式資料は、どれも自社のAPIに REST の語を使っています。

• OpenAI の API Reference は、後方互換性の項で「The REST API (currently v1)」と書き、大きな版の中では破壊的な変更をできる限り避けるとしています。
• Claude の API 概要は、冒頭で「The Claude API is a RESTful API at https://api.anthropic.com that provides programmatic access to Claude models and Claude Managed Agents.」（Claude API は https://api.anthropic.com にある RESTful API で、Claude のモデルと Claude Managed Agents へプログラムからアクセスできる）と書いています。
• Gemini の API リファレンスは、generateContent を「標準の REST エンドポイント」と呼び、「REST API は、HTTP リクエストをサポートする任意の環境で使用できます」と書いています。

一方で、REST ではない通信も同じ資料に並んでいます。OpenAI の資料は Realtime API を WebRTC・WebSocket・SIP で使う低遅延の音声用と書き、Gemini の資料は Live API を「WebSocket ベース」の双方向ストリーミング、streamGenerateContent をサーバー送信イベント（SSE）でチャンク（細切れ）を送る方式と書いています。文章を送って答えを1通で受け取る基本の呼び出しは REST の形で、音声の即時のやり取りなどは別の通信を使う、というのが公式資料から読み取れる分担です。

筆者が2026年10月8日4時54分に、鍵なしで OpenAI の chat/completions へ POST を送ると、HTTP 401 と「You didn't provide an API key.」（API キーが提供されていません）が返りました。鍵なしで呼んだ時の各社の断り方と APIキーの扱いはAPIとは、OpenAI の鍵の作り方と料金はOpenAI APIの使い方と料金にあります。

GraphQL とは何か。REST API と何が違うのか

GraphQL（グラフキューエル）は、GraphQL Foundation の入門ページによると次のものです。

GraphQL is a query language for your API, and a server-side runtime for executing queries using a type system you define for your data.

（訳）GraphQL は、API のためのクエリ言語であり、データに対して定義した型の仕組みを使ってクエリを実行するサーバー側の実行環境である。

「クエリ言語」とは、ほしいデータを書いて頼むための書き方、「型」とは、各項目が文字なのか数なのかといった決まりです。AWS の比較ページは、REST と GraphQL を、インターネット上でデータを交換するAPIを設計する2つの異なるアプローチと位置づけ、どちらもクライアントとサーバーのモデルで、HTTP ベースで、ステートレスで、JSON を返せる点は共通と書いています。

違いを AWS の表から、同じ観点で並べます。

AWS は使い分けの目安も書いています。GraphQL が向く例は、帯域が限られてリクエスト数を減らしたい時、複数のデータソースを1つの窓口にまとめたい時。REST が向く例は、アプリの規模が小さくデータが複雑でない時、すべてのクライアントが同じようにデータを使う時です。両方を1つのアプリで使う構成もできる、とも書いています。

注意したいのは、REST にも項目を絞れるAPIがあることです。上で呼んだ Open-Meteo は、URL に current=temperature_2m と書くと気温だけを返しました。AWS の表は一般的な傾向を述べたもので、どのRESTのAPIでも固定の構造しか返らない、という意味ではありません。

GitHub のドキュメントは、自社が GraphQL API を提供した理由を、必要なデータを正確に指定でき、必要なデータだけを取れる点が従来の REST API のエンドポイントより強力な利点であり、複数の REST 要求を1回の呼び出しに置き換えてデータを取得できるため、と書いています。GitHub は REST API と GraphQL API の両方を公開しています。

同じ種類の問い合わせを GraphQL に送ると、何が返ってきたのか

2026年10月8日4時54分、国の情報を返す公開 GraphQL サーバー（trevorblades/countries）に、鍵なしで問い合わせました。送り先は https://countries.trevorblades.com/graphql の1か所だけです。

3項目を頼むと72バイト、1項目だけなら40バイトで、頼んだ項目だけが返りました（同じサーバーでの比較で、REST との大きさの比較ではありません）。綴りを間違えた項目には、「capital のことですか」という提案つきのエラーが返り、これは AWS の「エラーメッセージが自動生成される」という説明に沿っています。

資料と食い違った点が2つあります。1つは、AWS が「内部的には、GraphQL はすべてのクライアントリクエストを POST HTTP リクエストとして送信します」と書くのに対し、GraphQL Foundation の「Serving over HTTP」は「must handle the HTTP POST method for query and mutation operations, and may also accept the GET method for query operations」（POST は必ず扱い、クエリの操作には GET も受け付けてよい）と書いていて、筆者の GET も通ったことです。GraphQL 側の資料のほうが、観測と合っています。もう1つは、同じページが、検証エラーでは「the server will typically send a 400 status code, although some legacy servers may return a 2xx status code when the application/json media type is used」（サーバーは通常 400 を返すが、古いサーバーは application/json の場合に 2xx を返すことがある）と書くのに、筆者が受け取ったステータスは 200 だったことです。このときの応答の形式（Content-Type）は application/json でした。curl は何も指定しないと「Accept: /」（どの形式でもよい）を送ります。同じ日の5時3分に、受け取りたい形式を伝える Accept ヘッダーで GraphQL 用の application/graphql-response+json を指定して同じ問い合わせを送り直すと 400 が返り、application/json を指定すると 200 のままでした。返す形式によってステータスが変わるという、このページの説明に沿った動きです。

REST では「何をするか」が動詞（GET・POST など）と URL で決まるのに対し、GraphQL は同じ1つの URL に、中身で「何がほしいか」を書いて送る、という違いが、この呼び出しで目に見えました。GraphQL Foundation も、GraphQL のサーバーは通常 /graphql という単一の URL で動くと説明しています。

Graph API は GraphQL のことなのか

Graph API は GraphQL とは別のものです。「Graph」は同じでも、前者は特定の会社の製品名、後者はクエリ言語の名前です。紛らわしいことに、GraphQL の仕様書（2021年10月版）は、GraphQL を「originally created at Facebook in 2012」（もとは2012年に Facebook で作られた）と書いています。筆者が公式ページで確かめた Graph API は2つあります。

• Meta（Facebook）の Graph API。 概要ページは、Facebook プラットフォームにデータを取り込み、取り出すための主要な手段で、HTTP ベースのAPIだと書いています。名前は、Facebook 上の情報を表す「ソーシャルグラフ」にちなみ、ノード（一意の ID を持つ個別のオブジェクト）、エッジ（2つのノードのつながり）、フィールド（ノードの属性）で構成されます。要求は graph.facebook.com に送り、/USER-ID/photos のような URL ごとに GET・POST・DELETE を使い分けます。ほとんどすべてのエンドポイントでアクセストークン（アプリが使うための許可の印）が必要です。2026年10月8日4時55分に、ログインせずにヘッドレスのブラウザで開いたこのページ（日本語表示）の本文には、GraphQL と REST のどちらの語も見当たりませんでした（5時11分に英語表示でも同じ）。
• Microsoft Graph。 概要ページは、Microsoft Entra や Microsoft 365 などの Microsoft クラウドサービスにおけるデータとインテリジェンスへのゲートウェイと書き、単一のエンドポイント https://graph.microsoft.com を提供し、REST API または SDK でアクセスすると説明しています。

「Graph API」と書かれたら、まずどの会社の資料かを見る必要があります。

REST API を自分で試すには、何から始めるのか

1. 鍵のいらない GET から試す。ブラウザのアドレスバーに URL を入れて開くと、返ってきた JSON が文字で表示されます。Open-Meteo のようなAPIの説明ページには、URL に付けるパラメータの一覧があります。筆者が呼んだ天気APIの apikey の項は「Only required to commercial use to access reserved API resources for customers.」（商用利用で顧客向けの専用リソースにアクセスする場合にだけ必要）と書いています。
2. データを送る呼び出し（POST・PUT・DELETE）は、練習用のダミーAPIで試す。JSONPlaceholder は、鍵も登録も要らず、実際のデータは変わらないと公式が書いています。
3. 鍵が要るAPI（ChatGPT・Claude・Gemini など）は、各社の公式の手順でキーを作り、キーを人に見せない。資料の読み方と料金は、Gemini APIの使い方やAI APIの料金比較にあります。
4. プログラムを書かずにアプリ同士をつなぎたいだけなら、API連携とはのように、ノーコードの道具が REST API を呼ぶ部分を肩代わりします。

うまくいかない時は、ステータスコード（401・404・429 などの意味は上の節）と、応答の本文のエラーメッセージを先に読みます。筆者が受け取った 401 や旧版の応答も、本文に理由が書かれていました。

この記事で確かめていない点は何か

• ログイン後の画面は見ていません。鍵を使った呼び出し（OpenAI・Claude・Gemini・GitHub・Meta・Microsoft の実際の応答）はしていません。各社の仕様は、ログインせずに読める公式資料に基づきます。
• 筆者が叩いた GraphQL は、公開の1サーバー（trevorblades/countries）だけです。GitHub の GraphQL も試みましたが、匿名の呼び出しが上限に達したという応答が返り、検証に使えなかったので、結果を本文に採用していません。
• 呼んだAPIが REST の制約をすべて守っているかは判定していません。MDN の言う「日常の呼び名としての REST API」の意味で書いています。
• Meta の Graph API の概要ページに GraphQL と REST の語が無かった、というのは、2026年10月8日に取得した概要ページ1枚（日本語表示と英語表示）の本文の範囲です。Meta のほかのページには書かれている可能性があります。
• GraphQL を HTTP で扱う決まり（GraphQL over HTTP）は、10月8日に取得した時点で草案（Current Working Draft）です。その草案は、検証に通らない要求には 422 を勧めています。上の 400／200 は、1つのサーバーでの観測です。

この記事が引いた REST・GraphQL の資料

MDN Web Docs、AWS、IBM、Roy Fielding の博士論文（2000年）、GraphQL Foundation と GraphQL の仕様書（2021年10月版・GraphQL over HTTP の草案）、GitHub・Meta・Microsoft・OpenAI・Claude・Google の公式資料、および呼び出しに使った JSONPlaceholder・Open-Meteo・trevorblades/countries です。取得時刻はいずれも2026年10月8日の4時52分から5時11分の間で、URL はこの記事の出典欄にあります。