【図解】REST APIとは？仕組みから設計原則、使い方までを初心者向けにわかりやすく解説

「REST API」という言葉を耳にするけれど、その仕組みや使い方を正しく理解できていますか？この記事では、Web開発の基本であるREST APIについて、その仕組みから設計原則、具体的な使い方までを図解を交えて初心者にも分かりやすく解説します。クライアントとサーバー間の通信の流れ、JSON形式でのデータ交換、Postmanを使った実践例までを網羅。さらに、SOAPやGraphQLとの違いも明確にすることで、なぜREST APIが多くのWebサービスで採用されているのか、その本質が理解できます。本記事を読めば、Webサービス連携の基礎を体系的に学べます。

REST APIとは そもそもAPIをわかりやすく解説

「REST API」という言葉を耳にしたことはありますか？現代のWebサービスやアプリケーション開発において、この技術は欠かせない存在となっています。しかし、言葉だけ聞くと「何だか難しそう…」と感じる方も多いかもしれません。この章では、REST APIを理解するための第一歩として、まず「API」そのものの概念から、身近な例えを使ってわかりやすく解説していきます。

APIを理解することで、普段私たちが利用しているWebサービスが、どのように連携し、便利な機能を提供しているのか、その裏側の仕組みが見えてくるはずです。それでは、APIの世界への扉を開けてみましょう。

APIを身近な自動販売機に例えると

API（Application Programming Interface）を最も直感的に理解するために、街角でよく見かける「自動販売機」を想像してみてください。自動販売機は、実はAPIの仕組みと非常によく似た役割を果たしています。

あなたがジュースを買いたいとき、以下の手順を踏みます。

1. お金を入れる（要求の準備）
2. 欲しいジュースのボタンを押す（具体的な要求を伝える）
3. ジュースが出てくる（要求の結果を受け取る）

この一連の流れにおいて、あなたは自動販売機の内部で「どうやってお金を識別しているのか」「どうやってボタンと商品を連動させているのか」「どうやって在庫を管理しているのか」といった複雑な仕組みを一切知る必要がありません。あなたはただ「ボタンを押す」という決められた操作方法さえ知っていれば、目的のジュースを手に入れることができます。

この関係性をプログラムの世界に置き換えてみましょう。

• あなた（利用者）：クライアント（APIを利用するアプリケーションやソフトウェア）
• 自動販売機：API（アプリケーション間の仲介役）
• 自動販売機の内部機構：サーバー（機能やデータを提供する本体）

つまりAPIとは、「内部の複雑な仕組みを隠蔽し、外部に対して決められた操作方法（インターフェース）だけを提供してくれる窓口」のようなものです。APIがあるおかげで、開発者は他のサービスやソフトウェアの機能を、その内部構造を詳しく知らなくても、まるで自分のプログラムの部品のように簡単かつ安全に利用できるのです。

Web APIとREST APIの関係性

「API」という言葉の基本的な意味がわかったところで、次に「Web API」と「REST API」の関係性について整理していきましょう。これらはよく混同されがちですが、それぞれが指す範囲が異なります。

まず、APIは非常に広い概念です。例えば、パソコンのOSが提供する機能（ファイルの読み書きなど）をアプリケーションから呼び出すための仕組みもAPIの一種です。これに対し、Web APIは、その名の通りWeb技術、具体的にはインターネット越しにHTTP/HTTPSという通信ルールを使って利用されるAPIを指します。

そしてREST APIは、数あるWeb APIの「設計思想」や「作り方のスタイル」の中で、現在最も広く採用されている主流なものを指します。RESTは「REpresentational State Transfer」の略で、Webを支える技術の利点を最大限に活かすための、いくつかの設計原則（ルール）の集まりです。この原則に従って作られたWeb APIが「REST API」と呼ばれます。

これらの関係性をまとめると、以下の表のようになります。

種類	概要	具体例・特徴
API	アプリケーション同士が情報をやり取りするための接点や窓口の総称。最も広い概念。	OSのAPI、プログラミング言語のライブラリAPI、Web APIなど
Web API	APIの中でも、インターネット経由でHTTP/HTTPSプロトコルを用いて利用されるもの。	天気予報API、地図情報API、SNSの投稿APIなど
REST API	Web APIの設計思想（アーキテクチャスタイル）の一つ。特定のルールに従って作られたWeb API。	現在のWeb APIの多くがこのスタイルを採用している。シンプルでわかりやすいのが特徴。

要するに、「API」という大きな枠組みの中に「Web API」があり、そのWeb APIをどのようなルールで作るかという設計スタイルの一つが「REST」である、と理解すると良いでしょう。次の章からは、このREST APIがどのような仕組みで動き、どのようなルール（原則）に基づいて設計されるのかを、さらに詳しく見ていきます。

【図解】REST APIの基本的な仕組み

REST APIがどのように機能するのか、その心臓部ともいえる基本的な仕組みを、図をイメージしながら理解していきましょう。REST APIにおける通信は、「クライアント」と「サーバー」という2つの登場人物が、明確なルールに基づいて情報をやり取りすることで成り立っています。ここでは、その役割分担と通信の具体的な流れ、そしてRESTの重要な特徴である「ステートレス性」について詳しく解説します。

クライアントとサーバーの役割分担

REST APIのアーキテクチャは、「クライアントサーバーモデル」に基づいています。これは、役割が明確に異なる「情報を要求する側（クライアント）」と「情報を提供する側（サーバー）」にシステムを分離する考え方です。この役割分担により、お互いが独立して開発や改修を進められるようになります。

クライアント（Client）
クライアントは、ユーザーが操作するアプリケーションやサービスのことを指します。例えば、皆さんが普段お使いのWebブラウザ、スマートフォンアプリ、または他のWebサービスなどがクライアントにあたります。クライアントの主な役割は、必要な情報を特定し、サーバーに対して「この情報が欲しい」「このデータを保存してほしい」といったリクエスト（要求）を送信することです。そして、サーバーから返ってきたレスポンス（応答）を受け取り、その結果を画面に表示したり、次の処理を行ったりします。

サーバー（Server）
サーバーは、データや機能といった「リソース（情報資源）」を管理し、クライアントからのリクエストに応じてそれらを提供する役割を担います。データベースにアクセスして情報を取得したり、新しいデータを保存したり、あるいは特定の計算処理を実行したりします。サーバーはクライアントからのリクエストを待ち受け、受け取ったリクエストの内容を解釈して適切な処理を実行し、その結果をレスポンスとしてクライアントに返却します。クライアントが何者であるか（Webブラウザなのかスマホアプリなのか）をサーバーは意識する必要はありません。

リクエストとレスポンスによる通信の流れ

クライアントとサーバーは、「リクエスト」と「レスポンス」という一対のメッセージを交換することで通信を行います。これは、レストランで客が注文（リクエスト）し、店員が料理を運んでくる（レスポンス）のに似ています。この一連の流れを具体的に見ていきましょう。

クライアントがサーバーに情報を要求してから、サーバーが応答を返すまでの基本的なステップは以下の通りです。

ステップ	担当	内容
1. リクエスト生成	クライアント	「どのリソース」に「何をしたいか」を定義したリクエストメッセージを作成します。例えば、「ユーザー情報（リソース）をください（操作）」といった内容です。
2. リクエスト送信	クライアント	作成したリクエストメッセージを、インターネットを通じてサーバーに送信します。
3. リクエスト受信と処理	サーバー	クライアントからのリクエストを受け取り、その内容を解析します。要求された操作（データの取得、作成、更新、削除など）を実行します。
4. レスポンス生成	サーバー	処理結果を基に、レスポンスメッセージを作成します。処理が成功したか失敗したかを示す「ステータスコード」と、要求されたデータ本体（ペイロード）などが含まれます。
5. レスポンス送信	サーバー	作成したレスポンスメッセージを、クライアントに返送します。
6. レスポンス受信と表示	クライアント	サーバーからのレスポンスを受け取り、内容を解析します。受け取ったデータを画面に表示したり、アプリケーションの内部で利用したりします。

この一回のリクエストとレスポンスのやり取りで、1つの通信が完結します。REST APIでは、このシンプルな通信を繰り返すことで、様々な機能を実現しています。

ステートレス性とは何か なぜ重要なのか

RESTの設計原則の中でも特に重要なのが「ステートレス（Stateless）」という性質です。ステートレスとは、「状態（State）を持たない（less）」という意味で、サーバーがクライアントの過去のやり取りや状態を一切記憶しないことを指します。

もう少し具体的に言うと、サーバーはクライアントから送られてきた各リクエストを、それぞれ完全に独立した、全く新しいリクエストとして扱います。以前に同じクライアントからどんなリクエストがあったか、といった文脈（コンテキスト）情報には依存しません。そのため、リクエストを処理するために必要な情報は、すべてリクエスト自体に含まれている必要があります。例えば、認証が必要なAPIであれば、ユーザーを識別するための認証トークンなどをリクエストの都度、含めて送信します。

このステートレス性がなぜ重要かというと、主に3つの大きなメリットがあるからです。

• スケーラビリティ（拡張性）の向上
  サーバーがクライアントの状態を管理する必要がないため、サーバーの台数を増やす「スケールアウト」が非常に容易になります。アクセスが急増した際に、ロードバランサー（負荷分散装置）がリクエストを空いているサーバーに振り分けるだけで対応できます。どのサーバーが応答しても、状態を保持していないため同じ結果を返すことができるからです。
• システムの単純化
  サーバー側でクライアントごとのセッション情報などを管理する複雑な仕組みが不要になるため、サーバーアプリケーションの設計や実装がシンプルになります。これにより、開発や保守のコストを抑えることができます。
• 信頼性・可用性の向上
  あるサーバーに障害が発生しても、クライアントは同じリクエストを別のサーバーに再送するだけで処理を継続できます。特定のサーバーに状態が依存していないため、障害の影響を最小限に抑えることが可能です。

このように、ステートレス性はREST APIがシンプルかつ柔軟で、大規模なシステムにも対応できる堅牢なアーキテクチャであるための根幹をなす重要な原則なのです。

REST APIを構成する4つの主要な要素

REST APIにおける通信は、いくつかの決まった要素を組み合わせて構成されています。クライアントがサーバーに「何がしたいか」を伝えるリクエストは、主に「URI」「HTTPメソッド」「HTTPヘッダー」「ペイロード」という4つの要素から成り立っています。これらの要素が連携することで、シンプルでわかりやすいAPI通信が実現されます。ここでは、それぞれの要素がどのような役割を担っているのかを詳しく見ていきましょう。

URI リソースの場所を示す住所

URI（Uniform Resource Identifier）とは、Web上に存在する「リソース」を一意に特定するための識別子のことです。リソースとは、ユーザー情報、商品データ、画像ファイルなど、APIを通じて操作したい対象となる情報やデータを指します。URIは、そのリソースがどこにあるのかを示す「インターネット上の住所」のような役割を果たします。

例えば、https://api.example.com/v1/users/123 というURIがあった場合、これは「example.comというサービスのAPI（バージョン1）の中にある、全ユーザー（users）のうち、IDが123番のユーザー」という特定のリソースを指し示しています。RESTの設計では、リソースの種類を複数形（例: /users, /products）で表現し、特定のリソースをその配下にIDで指定するのが一般的です。このURIを正しく指定することで、クライアントは目的のリソースに対して操作をリクエストできます。

HTTPメソッド リソースへの操作

HTTPメソッドは、URIで指定したリソースに対して「何を行いたいか」という操作の種類を示す動詞の役割を担います。例えば、データを「取得したい」のか、「新しく作成したい」のか、「更新したい」のか、「削除したい」のかをサーバーに伝えます。REST APIでは、主に以下のHTTPメソッドが使われます。これらは、データ操作の基本であるCRUD（Create, Read, Update, Delete）と対応しています。

GET データの取得

GETメソッドは、指定したURIのリソース情報を取得（Read）するために使用されます。APIで最も頻繁に使われるメソッドであり、例えばユーザーの一覧を取得したり、特定の商品の詳細情報を表示したりする際に利用されます。GETリクエストはサーバー上のデータを変更しないため、何度実行しても結果が変わらない「べき等性」と、副作用がない「安全性」を持つとされています。

POST データの新規作成

POSTメソッドは、新しいリソースを作成（Create）するために使用されます。例えば、新しいユーザーを登録したり、ブログに新しい記事を投稿したりする場合に利用します。作成したいデータの内容は、後述する「ペイロード」に含めてサーバーに送信します。同じPOSTリクエストを複数回送信すると、その都度新しいリソースが作成される可能性があるため、べき等性はありません。

PUT/PATCH データの更新

PUTメソッドとPATCHメソッドは、既存のリソースを更新（Update）するために使用されますが、その更新方法に違いがあります。

• PUT: リソース全体を完全に置き換えるためのメソッドです。例えば、ユーザー情報の一部だけを送信した場合、送信されなかった他の項目は空になったり、初期値に戻ったりする可能性があります。リソース全体を更新するため、何度実行しても結果は同じになり、「べき等性」があります。
• PATCH: リソースの一部だけを更新するためのメソッドです。例えば、ユーザーのメールアドレスだけを変更したい場合、メールアドレスの情報だけを送信すれば、他の項目に影響を与えることなく更新できます。より効率的な更新が可能ですが、操作内容によってはべき等性が保証されない場合もあります。

DELETE データの削除

DELETEメソッドは、指定したURIのリソースを削除（Delete）するために使用されます。例えば、特定のユーザーアカウントを削除したり、投稿したコメントを削除したりする場合に利用されます。一度リソースを削除した後に同じDELETEリクエストを再度送信しても、既に存在しないため状態は変わらず、結果として「べき等性」があります。

HTTPメソッド	CRUD操作	主な役割
GET	Read（読み取り）	リソースの取得
POST	Create（作成）	リソースの新規作成
PUT	Update（更新）	リソース全体の置換・更新
PATCH	Update（更新）	リソースの一部分の更新
DELETE	Delete（削除）	リソースの削除

HTTPヘッダー 通信の付加情報

HTTPヘッダーは、リクエストやレスポンスに関する追加情報（メタデータ）を格納する領域です。ここには、通信するデータの形式や、認証情報、キャッシュの制御情報など、通信を円滑に行うための重要な情報が含まれます。クライアントが送信する「リクエストヘッダー」と、サーバーが返す「レスポンスヘッダー」があります。

例えば、クライアントはリクエストヘッダーのContent-Typeで「これからJSON形式のデータを送ります」と伝えたり、Authorizationで「このAPIキーを使って認証してください」といった情報をサーバーに通知します。これにより、サーバーはリクエストを正しく解釈し、処理することができます。

ヘッダーフィールド	主な役割	使われる場面
Content-Type	送信するペイロード（本体）のデータ形式を指定する。	リクエスト/レスポンス
Accept	クライアントが受信したいデータ形式を指定する。	リクエスト
Authorization	認証トークンやAPIキーなど、認証情報をサーバーに伝える。	リクエスト
Cache-Control	レスポンスをキャッシュして良いか、その期間などを指定する。	レスポンス

ペイロード 送受信されるデータ本体

ペイロードとは、HTTPリクエストやレスポンスにおいて、実際に送受信されるデータ本体のことを指します。HTTPボディとも呼ばれます。例えば、POSTリクエストで新しいユーザーを作成する場合、そのユーザーの名前やメールアドレスといった具体的な情報がペイロードに含まれます。また、GETリクエストでユーザー情報を取得した際には、サーバーから返されるユーザー情報がレスポンスのペイロードとなります。

REST APIでは、このペイロードのデータ形式としてJSON（JavaScript Object Notation）が広く採用されています。JSONは{"key": "value"}という形式でデータを記述するフォーマットで、人間にとっても機械にとっても読み書きしやすく、軽量であるという特徴があります。この扱いやすさから、多くのプログラミング言語で標準的にサポートされており、現代のWeb API開発における事実上の標準となっています。

REST APIの設計における6つの原則

REST APIは、特定のルールに従って設計されることで、そのメリットを最大限に発揮します。このルールは「設計原則（制約）」と呼ばれ、提唱者であるロイ・フィールディング氏の論文で定義されています。これらの原則に従うことで、Webシステム全体として拡張性や柔軟性、長期的な運用性に優れたアーキテクチャを構築できます。ここでは、RESTをRESTたらしめる6つの重要な設計原則について、一つひとつ詳しく解説します。

クライアントサーバー分離

「クライアントサーバー分離（Client-Server）」は、ユーザーインターフェースを持つ「クライアント」と、データを管理する「サーバー」の役割を明確に分離するという原則です。クライアントは画面表示やユーザーからの入力を担当し、サーバーはデータの保存、ビジネスロジックの実行などを担当します。

この分離により、両者は互いに独立して開発・修正・拡張が可能になります。例えば、サーバー側の仕組みを変更することなく、Webブラウザ向けのフロントエンドに加えて、スマートフォンアプリ（クライアント）を新たに開発できます。逆に、クライアントの見た目を変更しても、サーバー側のロジックに影響はありません。このように関心事を分離することで、開発効率が向上し、システムの各部分を独立してスケールさせることが容易になります。

ステートレス

「ステートレス（Stateless）」は、サーバーがクライアントの過去のリクエスト履歴やセッション状態を一切保持しないという原則です。クライアントからサーバーへの各リクエストは、それ自体で完結しており、サーバーがリクエストを処理するために必要な情報がすべて含まれている必要があります。

例えば、ユーザーがログインしている状態を維持するために、クライアントはリクエストのたびに認証情報（APIトークンなど）をHTTPヘッダーに含めて送信します。サーバー側では「前回のAというリクエストの続き」といった文脈を記憶しません。これにより、サーバーはどのリクエストも個別に対応できるため、負荷分散（ロードバランシング）が容易になり、システム全体の拡張性（スケーラビリティ）と信頼性が大幅に向上します。

キャッシュ可能性

「キャッシュ可能性（Cacheability）」は、サーバーからのレスポンスに、そのデータをクライアント側で一時的に保存（キャッシュ）してよいかどうかを示す情報を含めるべき、という原則です。頻繁に更新されないデータであれば、クライアントや中間のプロキシサーバーが一度取得したデータを再利用することで、サーバーへの問い合わせを減らせます。

具体的には、HTTPヘッダーの`Cache-Control`などを用いて「このデータは1時間キャッシュ可能」といった指定を行います。これにより、同じリクエストを何度もサーバーに送る必要がなくなり、レスポンス速度の向上によるユーザー体験の改善と、サーバーの負荷軽減という両方のメリットが得られます。

統一インターフェース

「統一インターフェース（Uniform Interface）」は、RESTの最も中核となる原則です。クライアントとサーバーがやり取りするためのインターフェース（接続方法や表現形式）を、あらかじめ決められた方法に統一することで、システム全体をシンプルに保ち、両者の疎結合を促進します。この原則は、さらに以下の4つのサブ制約から構成されます。

サブ制約	説明
リソースの識別	すべての情報（リソース）は、URI（例: /users/123）によって一意に識別されます。URIがリソースの「住所」の役割を果たします。
表現によるリソースの操作	クライアントがリソースを直接操作するのではなく、リソースの「表現」（JSONやXML形式のデータ）を取得・更新・削除します。サーバーから受け取った表現を編集して送り返すことで、サーバー上のリソースの状態が変更されます。
自己記述的メッセージ	リクエストやレスポンスといった各メッセージ自体が、そのメッセージをどう処理すればよいかを理解するための情報を含んでいる必要があります。例えば、HTTPヘッダーにContent-Type: application/jsonと記述することで、データ本体がJSON形式であることを示します。
HATEOAS (Hypermedia as the Engine of Application State)	レスポンスの中に、そのリソースに関連する次の操作（状態遷移）を行うためのリンク（ハイパーメディア）を含めるという考え方です。これにより、クライアントはAPIの仕様書をすべて知らなくても、レスポンスに含まれるリンクを辿ってアプリケーションを操作できます。

これらの制約に従うことで、APIの利用方法が標準化され、特定のプログラミング言語やプラットフォームに依存しない、汎用性の高いシステムを構築できます。

階層化システム

「階層化システム（Layered System）」は、クライアントとサーバーの間に、複数の階層（レイヤー）を置くことを許容する原則です。例えば、クライアントとAPIサーバーの間に、セキュリティチェックを行うためのAPIゲートウェイや、負荷を分散させるためのロードバランサー、キャッシュを保持するプロキシサーバーなどを配置できます。

この原則の重要な点は、クライアントは通信相手であるサーバーの先に、どのような階層が存在するのかを意識する必要がないことです。クライアントは常に直接の接続先とだけ通信します。これにより、システム全体の構成を柔軟に変更でき、セキュリティの強化やスケーラビリティの向上といった要件に後から対応することが容易になります。

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

「コードオンデマンド（Code on Demand）」は、これまで紹介した5つの原則とは異なり、唯一のオプション（任意）の制約です。これは、サーバーがクライアントに対して、ロジックを含んだプログラムコード（例えばJavaScript）を送信し、クライアント側でそのコードを実行させることを許可するという考え方です。

WebブラウザがWebページからJavaScriptをダウンロードして実行するのが、この原則の身近な例です。クライアントの機能をサーバー側から一時的に拡張できるため柔軟性が増しますが、実装が複雑になり、セキュリティ上のリスクも考慮する必要があるため、一般的なREST APIの設計で積極的に利用されることは稀です。

REST APIの簡単な使い方と実践例

ここまではREST APIの仕組みや設計原則といった理論的な側面を解説してきました。この章では、実際に手を動かしながらREST APIの使い方を体験してみましょう。具体的なツールやプログラミング言語を使ってAPIを呼び出すことで、これまでの説明がより深く理解できるはずです。今回は、APIテストツールとして広く使われている「Postman」と、Webフロントエンド開発で必須の技術である「JavaScript」を使った2つの実践例をご紹介します。

Postmanを使ったREST APIの実行方法

Postmanは、APIの開発やテストを効率化するための非常に強力なGUIツールです。プログラミングコードを書かなくても、直感的な操作で簡単にREST APIへリクエストを送信し、そのレスポンスを確認できます。多くの開発現場で標準的に利用されており、REST APIの動作を学ぶ第一歩として最適です。

ここでは、架空のブログサービスAPIを例に、Postmanの基本的な使い方を見ていきましょう。

基本的な操作の流れ

1. リクエストの作成: Postmanを起動し、「+」ボタンをクリックして新しいリクエストタブを開きます。
2. HTTPメソッドの選択: ドロップダウンリストから、実行したい操作に対応するHTTPメソッド（GET, POST, PUT, DELETEなど）を選択します。
3. URIの入力: リクエストを送信する先のURI（エンドポイントURL）を入力します。例えば、https://api.example.com/posts のような形式です。
4. リクエスト内容の設定（必要な場合）:
   • Headers: HTTPヘッダーを設定します。認証用のトークン（Authorizationヘッダー）や、送信するデータ形式（Content-Typeヘッダー）などを指定します。
   • Body: POSTやPUTリクエストでサーバーにデータを送信する場合、このタブで送信するデータ（ペイロード）を作成します。データ形式（raw、form-dataなど）を選択し、JSONなどを入力します。
5. リクエストの送信: 「Send」ボタンをクリックすると、設定した内容でリクエストがサーバーに送信されます。
6. レスポンスの確認: 画面下部にサーバーからのレスポンスが表示されます。レスポンスボディ（データ本体）、ステータスコード（例: 200 OK）、レスポンスヘッダーなどを確認できます。

実践例1: GETリクエストで記事一覧を取得する

すべての記事情報を取得するGETリクエストを送信してみます。

• メソッド: GET
• URI: https://api.example.com/posts

「Send」ボタンを押すと、レスポンスのBody部分に、以下のようなJSON形式の記事データ一覧が返ってきます。ステータスコードは「200 OK」と表示されるはずです。

実践例2: POSTリクエストで新しい記事を作成する

次に、新しい記事を投稿するPOSTリクエストを送信します。この場合、送信するデータ（ペイロード）をBodyに設定する必要があります。

• メソッド: POST
• URI: https://api.example.com/posts
• Headers: Content-Typeキーにapplication/jsonの値を設定します。
• Body: 「raw」を選択し、形式として「JSON」を選び、以下の内容を入力します。

「Send」ボタンを押すと、サーバー側で新しい記事が作成され、レスポンスとして作成されたリソースの情報が返ってきます。ステータスコードは「201 Created」となるのが一般的です。

このように、Postmanを使うことで、コードを書かずにREST APIの挙動を簡単にテスト・確認できます。

JavaScriptのfetch関数を使った呼び出し例

WebアプリケーションのフロントエンドからREST APIを呼び出す際に、現在最も一般的に使われているのがJavaScriptのfetch関数です。これはブラウザに標準で搭載されている機能で、非同期的にHTTPリクエストを扱うことができます。ここでは、fetch関数を使ってAPIを呼び出す基本的な方法を解説します。

GETリクエストでデータを取得する

まずは、APIからデータを取得する最もシンプルなGETリクエストの例です。fetchはPromiseを返すため、.then()で成功時の処理を、.catch()で失敗時の処理を記述します。

最近では、より直感的に書けるasync/await構文がよく使われます。同じ処理をasync/awaitで書くと以下のようになります。

POSTリクエストでデータを送信する

データを新規作成するPOSTリクエストでは、fetch関数の第二引数にオプションオブジェクトを渡して、メソッド、ヘッダー、ボディを指定します。

このコードでは、JavaScriptオブジェクトであるnewPostをJSON.stringify()でJSON形式の文字列に変換してリクエストボディに設定しています。また、headersでContent-Typeをapplication/jsonと指定することで、サーバーに送信するデータがJSONであることを伝えています。これらはPOSTリクエストを行う際の重要なポイントです。

REST APIでよく使われるデータ形式JSONとは

REST APIでクライアントとサーバーがデータをやり取りする際、そのデータは特定の形式（フォーマット）に従っている必要があります。現在、そのデータ形式として最も広く利用されているのがJSON（JavaScript Object Notation）です。

JSONは、JavaScriptのオブジェクトリテラル記法をベースにした、軽量なテキストベースのデータ交換フォーマットです。人間にとって読み書きがしやすく、プログラムにとっても解釈（パース）が容易であるという大きな利点があります。そのため、Web APIだけでなく、様々なアプリケーションの設定ファイルなどにも利用されています。

JSONの基本構造

JSONのデータ構造は非常にシンプルで、以下の2つの組み合わせで構成されます。

• オブジェクト: { }（波括弧）で囲まれた、キーと値のペアの集まりです。キーは文字列で、値には後述するデータ型が使えます。例: { "name": "Taro Yamada", "age": 30 }
• 配列: [ ]（角括弧）で囲まれた、値の順序付きリストです。例: [ "Tokyo", "Osaka", "Nagoya" ]

これらのオブジェクトと配列を入れ子にすることで、複雑なデータ構造も表現できます。

JSONで利用できるデータ型

JSONの値として使用できるデータ型は以下の通りです。

データ型	書き方の例	説明
文字列 (String)	"こんにちは"	ダブルクォーテーション (") で囲んだテキスト。
数値 (Number)	123, -45.6	整数または浮動小数点数。
真偽値 (Boolean)	true, false	真 (true) または偽 (false) を表す値。
null	null	値が存在しないことを示す特別な値。
オブジェクト (Object)	{ "key": "value" }	キーと値のペアの集まり。
配列 (Array)	[ 1, 2, 3 ]	値の順序付きリスト。

JSONの具体例

以下は、一人のユーザー情報をJSONで表現した具体例です。オブジェクト、配列、そして様々なデータ型が組み合わさっていることがわかります。

このように、REST APIではクライアントとサーバーがJSON形式のデータを相互に送受信することで、アプリケーションが機能しています。

REST APIのメリットとデメリット

REST APIは、そのシンプルさや柔軟性から、現在のWeb開発におけるAPI設計の主流となっています。多くのシステムで採用されているのには明確な理由がありますが、一方で利用シーンによってはデメリットとなり得る側面も存在します。ここでは、REST APIが持つメリットとデメリットを詳しく解説し、技術選定の判断材料を提供します。

まず、REST APIの主なメリットとデメリットを一覧で確認しましょう。

分類	概要
メリット	シンプルで学習コストが低く、異なる環境でも利用できる柔軟性と拡張性（スケーラビリティ）に優れています。また、キャッシュを利用することで高いパフォーマンスを発揮します。
デメリット	厳密な規格がないため設計にばらつきが出やすく、取得したい情報によっては通信回数が増えることがあります。また、ステートレスであるため状態管理が複雑になる場合があります。

これらの点を理解することは、REST APIを効果的に活用する上で非常に重要です。以下で、それぞれの項目についてより深く掘り下げていきます。

REST APIを利用する3つのメリット

REST APIが広く支持される背景には、主に3つの大きなメリットがあります。これらの利点により、開発効率の向上やシステムの安定運用が期待できます。

1. シンプルさとわかりやすさによる開発効率の向上

REST APIの最大のメリットは、その構造が非常にシンプルで直感的であることです。「どのリソース（URI）に」「どのような操作（HTTPメソッド）を行うか」が明確に示されるため、APIの仕様を容易に理解できます。例えば、「/users/123」というURIに対してGETメソッドを使えばユーザー情報を取得し、DELETEメソッドを使えばユーザー情報を削除するといった操作が、URLとメソッド名から直感的に推測できます。また、データのやり取りにはJSONのような軽量で人間にも読みやすいデータ形式が主に使われるため、開発者は迅速に実装を進めることが可能です。この学習コストの低さと扱いやすさは、開発チーム全体の生産性を高める大きな要因となります。

2. 高い柔軟性とスケーラビリティ

RESTの設計原則である「クライアントサーバー分離」と「ステートレス」は、システムに高い柔軟性と拡張性（スケーラビリティ）をもたらします。クライアント（Webブラウザやスマートフォンアプリなど）とサーバー（APIを提供するシステム）が完全に独立しているため、それぞれを別のプログラミング言語で開発したり、個別に改修・拡張したりすることが容易です。サーバー側の実装を変更しても、APIのインターフェース仕様さえ守られていればクライアント側に影響を与えません。また、HTTPというWebの標準プロトコルをベースにしているため、特定のプラットフォームに縛られることなく、多種多様なデバイスやサービスと連携できる点も大きな強みです。

3. Web標準技術の活用による高いパフォーマンス

REST APIは、HTTPプロトコルの機能を最大限に活用することで、高いパフォーマンスを実現します。特に「キャッシュ可能性」の原則は重要です。一度取得したデータ（レスポンス）をクライアント側や中間サーバーで一時的に保存（キャッシュ）しておくことで、同じリクエストを再度サーバーに送信する必要がなくなります。これにより、サーバーの負荷が軽減されるとともに、ユーザーへの応答速度が向上します。また、ステートレスな通信であるため、サーバーは各クライアントの状態を記憶する必要がなく、リクエストを個別に処理することに集中できます。これもサーバーリソースの効率的な利用とパフォーマンス向上に貢献します。

REST APIのデメリットと注意点

多くのメリットを持つREST APIですが、万能というわけではありません。プロジェクトの要件によっては、以下のようなデメリットが課題となる可能性があります。

1. 統一された厳密な規格がない

RESTは、SOAPのような厳格なプロトコルではなく、あくまで「アーキテクチャスタイル（設計思想）」です。そのため、実装方法に幅があり、開発者によって設計にばらつきが生まれやすいという側面があります。例えば、URIの命名規則やエラーレスポンスの形式、バージョニングの方法などがプロジェクトごとに異なり、一貫性のないAPIが作られてしまうリスクがあります。この問題を回避するためには、OpenAPI (Swagger) などのツールを用いてAPI仕様を明確にドキュメント化し、チーム内で設計ルールを徹底することが不可欠です。

2. エンドポイントの増加と通信回数の問題

REST APIはリソースごとにURI（エンドポイント）を定義する設計が基本です。そのため、アプリケーションが複雑化し、扱うリソースが増えるにつれて、管理すべきエンドポイントの数が膨大になる傾向があります。また、1つの画面を表示するために複数の異なるリソースの情報が必要な場合、クライアントは複数のエンドポイントに対して何度もAPIリクエストを送信しなければならないことがあります。例えば、ユーザー情報と、そのユーザーの投稿一覧を同時に取得したい場合、「/users/1」と「/users/1/posts」という2つのAPIを呼び出す必要があります。これは「オーバーフェッチング（不要な情報まで取得してしまう）」や「アンダーフェッチング（情報が足りず追加のリクエストが必要になる）」といった問題を引き起こし、特に通信環境が不安定なモバイルアプリなどではパフォーマンスの低下につながる可能性があります。

3. ステートレスに起因する状態管理の複雑さ

「ステートレス」であることはサーバーの拡張性を高めるメリットである一方、デメリットにもなり得ます。サーバーがクライアントの状態を保持しないため、複数回のリクエストにまたがる一連の操作（例：ECサイトのショッピングカート機能）を実現する場合、状態を管理する責任はすべてクライアント側に委ねられます。また、認証・認可においても、保護されたリソースにアクセスするたびに、リクエストにアクセストークンなどの認証情報を含める必要があります。これによりクライアント側の実装が複雑になったり、リクエストごとに送信するデータ量が増加したりする場合があります。

RESTと他のAPI（SOAP・GraphQL）との違い

Web APIを構築する際、RESTは非常に人気のある選択肢ですが、唯一の方法ではありません。プロジェクトの要件や特性によっては、他の技術が適している場合もあります。ここでは、RESTとしばしば比較される代表的なAPI技術である「SOAP」と「GraphQL」との違いを詳しく解説します。それぞれの特徴を理解することで、技術選定の際に適切な判断ができるようになります。

SOAPとの比較

SOAP（Simple Object Access Protocol）は、RESTが登場する以前から広く利用されてきた、W3Cによって標準化された厳格なプロトコルです。特に、高い信頼性やセキュリティが求められるエンタープライズシステム間の連携などで利用されてきました。

RESTとSOAPの最も大きな違いは、RESTが柔軟な「アーキテクチャスタイル（設計思想）」であるのに対し、SOAPは厳格に定められた「プロトコル（通信規約）」であるという点です。この根本的な違いが、データ形式や通信方法など、様々な側面に影響を与えています。

例えば、データ形式において、SOAPはXMLの使用が必須です。一方、RESTはJSON、XML、HTMLなど、クライアントとサーバーが合意した任意の形式を利用でき、特にWebで標準的に扱われるJSONとの親和性が高いという特徴があります。JSONはXMLに比べて軽量で記述もシンプルなため、パフォーマンス向上に寄与します。

また、SOAPはHTTPだけでなく、SMTP（メール送受信プロトコル）など、様々な通信プロトコル上で動作するように設計されています。対照的に、RESTは事実上HTTP/HTTPSを前提としており、Webの仕組みを最大限に活用するスタイルです。

以下の表に、RESTとSOAPの主な違いをまとめます。

項目	REST	SOAP
概念	アーキテクチャスタイル（設計思想）	プロトコル（厳格な通信規約）
データ形式	JSON、XML、HTMLなど柔軟に選択可能	XMLのみ
通信プロトコル	主にHTTP/HTTPS	HTTP、SMTP、TCPなど様々
パフォーマンス	軽量で、キャッシュを利用しやすいため一般的に高速	ヘッダー情報が多く、XMLの解析も必要なため比較的低速
柔軟性	設計の自由度が高い	規約が厳格で、拡張性が低い
標準化	特定の標準化団体はない	W3Cによって標準化されている

GraphQLとの比較

GraphQLは、Facebook（現Meta）社が開発し、2015年にオープンソース化されたAPIのための「クエリ言語」および「サーバーサイドランタイム」です。RESTが抱えていた課題、特に「オーバーフェッチング（不要なデータまで取得してしまう問題）」や「アンダーフェッチング（一度のリクエストで必要なデータが揃わず、複数回のリクエストが必要になる問題）」を解決するために生まれました。

RESTとGraphQLの最大の違いは、データ取得の主導権がどこにあるかです。RESTでは、サーバー側がエンドポイントごとに返すデータ構造を決定します。例えば、/users/1というエンドポイントは、常に決まったユーザー情報のセットを返します。もし名前だけが必要な場合でも、住所や電話番号など不要な情報まで一緒に取得してしまいます（オーバーフェッチング）。

一方、GraphQLでは、クライアント側が必要なデータを「クエリ」として記述し、リクエストします。サーバーは、そのクエリで指定されたデータだけを過不足なく返します。これにより、クライアントは必要な情報だけを一度のリクエストで効率的に取得できます。

この違いは、APIのエンドポイントの構造にも現れます。RESTでは、リソース（ユーザー、投稿など）ごとに複数のエンドポイント（例: /users, /posts）を用意します。対してGraphQLは、通常/graphqlのような単一のエンドポイントを持ち、そこに様々なクエリを送信することで、あらゆるデータ操作を行います。

以下の表に、RESTとGraphQLの主な違いをまとめます。

項目	REST	GraphQL
概念	アーキテクチャスタイル	クエリ言語およびランタイム
エンドポイント	リソースごとに複数存在する	通常、単一のエンドポイントに集約される
データ取得	サーバー主導（エンドポイントごとに固定）	クライアント主導（クエリで必要なデータを指定）
レスポンス形式	エンドポイントごとに固定された構造	リクエストしたクエリに応じた柔軟な構造
バージョニング	APIの変更時に/v2/のようにパスで管理することが多い	スキーマの拡張で対応しやすく、バージョニングが不要な場合が多い
適した用途	シンプルなCRUD操作、リソース指向の設計が明確な場合	複雑なデータ要求、モバイルアプリなど多様なクライアントが存在する場合

まとめ

本記事では、REST APIの基本的な仕組みから設計原則、具体的な使い方までを図解を交えて解説しました。REST APIは、ステートレス性や統一インターフェースといったシンプルな原則に基づいているため、柔軟で拡張性の高いWebサービス開発を可能にします。このわかりやすさが、多くのシステムで採用されている結論的な理由です。

PostmanやJavaScriptのfetch関数を使えば、初心者でも簡単にその動作を試せます。現代のWeb開発に不可欠な知識であるREST APIを理解し、ぜひ実際の開発に活かしてみてください。