この記事の最終更新日: 2026年5月23日

Web開発を学んでいると、ほぼ必ず出てくる言葉が API です。
たとえば、次のような場面でAPIという言葉を見かけます。
- 外部サービスのAPIを使う
- フロントエンドからAPIを呼び出す
- REST APIを設計する
- APIレスポンスをJSONで受け取る
- API連携を実装する
ただ、初心者のうちは次のように感じることも多いと思います。
APIって結局何?
REST APIとは何が違うの?
エンドポイントやリクエストって何?
フロントエンドとバックエンドの間で何が起きているの?
この記事では、REST APIを理解する前提として知っておきたい APIの基本 を、初心者向けにわかりやすく解説します。
APIとは何か?
APIとは、Application Programming Interface の略です。
日本語にすると「アプリケーション同士がやり取りするための接点」や「プログラムから機能を利用するための窓口」のような意味です。
もう少し簡単に言うと、APIとは次のようなものです。
あるシステムの機能やデータを、別のシステムから使えるようにするための仕組み
たとえば、天気アプリを考えてみましょう。
スマホの天気アプリは、自分自身で気温や降水確率を観測しているわけではありません。
多くの場合、天気情報を提供しているサーバーに問い合わせて、現在の天気や週間予報のデータを取得しています。
このとき、天気アプリが天気情報を取得するために使う窓口がAPIです。
APIを身近な例で考える
APIは、レストランの注文にたとえるとわかりやすいです。
レストランで料理を注文するとき、お客さんは厨房に直接入って料理を作るわけではありません。
お客さんはメニューを見て、店員さんに注文します。
すると、店員さんが厨房に注文を伝え、料理が完成したらお客さんのもとに運んでくれます。
この流れをAPIに置き換えると、次のようになります。
| レストラン | APIの世界 |
|---|---|
| お客さん | クライアント |
| 店員さん | API |
| 厨房 | サーバー・システム |
| メニュー | API仕様 |
| 注文 | リクエスト |
| 料理 | レスポンス |
つまりAPIは、利用者がシステム内部を直接触らなくても、決められた方法で機能やデータを利用できるようにする窓口です。
APIはWeb APIだけではない
APIというと、Web APIをイメージする人が多いかもしれません。
しかし、APIはWebの世界だけのものではありません。
たとえば、次のようなものもAPIです。
| 種類 | 例 |
|---|---|
| Web API | 天気API、決済API、Google Maps API |
| ライブラリのAPI | JavaScriptの配列操作、Laravelのメソッド |
| OSのAPI | ファイル操作、通知、カメラ、位置情報 |
| アプリ内API | モジュールやクラスが提供するメソッド |
たとえば、JavaScriptで次のようなコードを書くことがあります。
const numbers = [1, 2, 3];
numbers.map((number) => number * 2);
この map() も、配列が提供しているAPIの一種です。
開発者は配列の内部構造を細かく知らなくても、map() という決められた使い方をすれば、配列の各要素を変換できます。
このように、APIとは広い意味では「機能を使うために公開された操作方法」です。
Web APIとは何か?
Web APIとは、HTTP通信を使って利用するAPIです。
Webアプリケーションでは、フロントエンドとバックエンドが分かれていることがよくあります。
たとえば、次のような構成です。
ブラウザ・スマホアプリ
↓
API
↓
サーバー
↓
データベース
ユーザーが画面でボタンを押すと、ブラウザやスマホアプリがサーバーにリクエストを送ります。
サーバーはリクエストを受け取り、必要に応じてデータベースから情報を取得したり、データを保存したりします。
その結果を、JSONなどの形式でクライアントに返します。
このやり取りの窓口がWeb APIです。
API通信の基本的な流れ
API通信では、基本的に次の流れが発生します。
1. クライアントがリクエストを送る
2. サーバーがリクエストを受け取る
3. サーバーが処理を実行する
4. サーバーがレスポンスを返す
5. クライアントがレスポンスを受け取って画面に反映する
たとえば、ユーザー一覧を表示する画面を考えてみます。
フロントエンドは、次のようなAPIを呼び出します。
GET /users
サーバーはユーザー一覧を取得し、次のようなJSONを返します。
[
{
"id": 1,
"name": "山田太郎",
"email": "yamada@example.com"
},
{
"id": 2,
"name": "佐藤花子",
"email": "sato@example.com"
}
]
フロントエンドはこのレスポンスを受け取り、画面にユーザー一覧を表示します。
クライアントとサーバー
APIを理解するうえで重要なのが、クライアント と サーバー です。
クライアントとは
クライアントとは、APIを利用する側です。
たとえば、次のようなものがクライアントになります。
- ブラウザ
- スマホアプリ
- フロントエンドアプリ
- 他のサーバー
- 外部サービス
クライアントは、必要なデータや処理をサーバーに依頼します。
サーバーとは
サーバーとは、APIを提供する側です。
クライアントからリクエストを受け取り、処理を実行してレスポンスを返します。
たとえば、次のような処理を担当します。
- ユーザー情報を取得する
- 商品情報を登録する
- ログイン認証を行う
- 注文データを保存する
- 決済処理を実行する
つまり、クライアントは「お願いする側」、サーバーは「処理して返す側」です。
リクエストとは?
リクエストとは、クライアントからサーバーに送る依頼のことです。
たとえば、次のような依頼があります。
- ユーザー一覧を取得したい
- 新しい記事を作成したい
- 商品情報を更新したい
- コメントを削除したい
APIのリクエストには、主に次の情報が含まれます。
| 項目 | 内容 |
|---|---|
| URL | どのAPIにアクセスするか |
| HTTPメソッド | 何をしたいか |
| ヘッダー | 認証情報やデータ形式など |
| ボディ | 登録・更新したいデータなど |
たとえば、新しいユーザーを作成するリクエストは次のようになります。
POST /users
Content-Type: application/json
{
"name": "山田太郎",
"email": "yamada@example.com"
}
レスポンスとは?
レスポンスとは、サーバーからクライアントに返される結果です。
レスポンスには、主に次の情報が含まれます。
| 項目 | 内容 |
|---|---|
| ステータスコード | 処理結果を表す番号 |
| ヘッダー | レスポンスの情報 |
| ボディ | 実際のデータやエラーメッセージ |
たとえば、ユーザー作成に成功した場合、次のようなレスポンスが返ります。
201 Created
Content-Type: application/json
{
"id": 1,
"name": "山田太郎",
"email": "yamada@example.com"
}
失敗した場合は、次のようなレスポンスが返ることもあります。
422 Unprocessable Entity
Content-Type: application/json
{
"message": "入力内容に誤りがあります",
"errors": {
"email": ["メールアドレスの形式が正しくありません"]
}
}
APIでは、成功時だけでなく、失敗時のレスポンス設計も重要です。
エンドポイントとは?
エンドポイントとは、APIにアクセスするためのURLのことです。
たとえば、次のようなものがエンドポイントです。
GET /users
GET /users/1
POST /users
PUT /users/1
DELETE /users/1
エンドポイントは、「どのリソースに対して操作するか」を表します。
たとえば、ユーザーに関するAPIであれば、次のように設計できます。
| 操作 | エンドポイント |
|---|---|
| ユーザー一覧を取得 | GET /users |
| 特定のユーザーを取得 | GET /users/1 |
| ユーザーを作成 | POST /users |
| ユーザーを更新 | PUT /users/1 |
| ユーザーを削除 | DELETE /users/1 |
このように、エンドポイントを見ると、何に対するAPIなのかがわかります。
HTTPメソッドとは?
HTTPメソッドとは、リクエストで「何をしたいのか」を表すものです。
代表的なHTTPメソッドには、次のようなものがあります。
| HTTPメソッド | 役割 |
|---|---|
| GET | データを取得する |
| POST | データを作成する |
| PUT | データ全体を更新する |
| PATCH | データの一部を更新する |
| DELETE | データを削除する |
たとえば、ユーザー情報を取得したい場合はGETを使います。
GET /users/1
新しいユーザーを作成したい場合はPOSTを使います。
POST /users
ユーザー情報を更新したい場合はPUTやPATCHを使います。
PUT /users/1
PATCH /users/1
ユーザーを削除したい場合はDELETEを使います。
DELETE /users/1
REST APIを理解するうえで、このHTTPメソッドの役割はとても重要です。
JSONとは?
JSONとは、APIでよく使われるデータ形式です。
正式には JavaScript Object Notation といいます。
たとえば、ユーザー情報をJSONで表すと次のようになります。
{
"id": 1,
"name": "山田太郎",
"email": "yamada@example.com"
}
JSONは、人間にも読みやすく、プログラムでも扱いやすい形式です。
Web APIでは、リクエストやレスポンスのデータ形式としてJSONがよく使われます。
たとえば、フロントエンドがAPIから次のJSONを受け取ったとします。
{
"title": "APIとは何か?",
"status": "published"
}
JavaScriptでは、このデータを使って画面にタイトルや公開状態を表示できます。
ステータスコードとは?
ステータスコードとは、APIの処理結果を表す3桁の番号です。
代表的なステータスコードには、次のようなものがあります。
| ステータスコード | 意味 |
|---|---|
| 200 OK | 成功 |
| 201 Created | 作成成功 |
| 204 No Content | 成功したが返すデータはない |
| 400 Bad Request | リクエストが不正 |
| 401 Unauthorized | 認証が必要 |
| 403 Forbidden | 権限がない |
| 404 Not Found | データが見つからない |
| 422 Unprocessable Entity | 入力内容に誤りがある |
| 500 Internal Server Error | サーバー内部エラー |
たとえば、存在しないユーザーを取得しようとした場合、次のようなレスポンスが返ることがあります。
404 Not Found
{
"message": "ユーザーが見つかりません"
}
ステータスコードを見ることで、クライアントは「成功したのか」「失敗したのか」「なぜ失敗したのか」を判断できます。
API仕様とは?
API仕様とは、そのAPIをどのように使えばよいかをまとめたルールです。
API仕様には、主に次のような内容が書かれます。
- エンドポイント
- HTTPメソッド
- リクエストパラメータ
- リクエストボディ
- レスポンス形式
- ステータスコード
- 認証方法
- エラー時の形式
たとえば、ユーザー作成APIの仕様は次のように書けます。
POST /users
リクエスト:
{
"name": "山田太郎",
"email": "yamada@example.com"
}
レスポンス:
201 Created
{
"id": 1,
"name": "山田太郎",
"email": "yamada@example.com"
}
API仕様が明確だと、フロントエンドとバックエンドで認識を合わせやすくなります。
逆に、API仕様が曖昧だと、次のような問題が起こりやすくなります。
- どのURLを呼べばよいかわからない
- どの項目を送ればよいかわからない
- エラー時の処理が書けない
- フロントエンドとバックエンドで認識がずれる
- 実装後に手戻りが発生する
APIは「なんとなく作るもの」ではなく、利用者との約束として設計することが大切です。
APIとデータベースの違い
初心者のうちは、APIとデータベースの違いがわかりにくいことがあります。
簡単に言うと、APIはデータベースそのものではありません。
APIは、データベースにアクセスするための窓口です。
クライアント
↓
API
↓
サーバー処理
↓
データベース
たとえば、ユーザー一覧を取得する場合、クライアントはデータベースに直接アクセスしません。
クライアントはAPIにリクエストを送ります。
サーバーはAPI経由でリクエストを受け取り、必要な処理を行ったうえで、データベースからユーザー情報を取得します。
その結果をJSONとしてクライアントに返します。
つまり、APIはデータベースを安全に、決められた形で利用するための窓口です。
なぜAPIが必要なのか?
APIが必要な理由は、システム同士を安全かつ効率的につなぐためです。
1. システム内部を隠せる
クライアントは、サーバー内部の実装を知る必要がありません。
たとえば、データベースがMySQLなのかPostgreSQLなのか、サーバーがLaravelなのかRailsなのかを、クライアントは気にしなくてよいです。
APIの使い方さえ決まっていれば、内部実装を変更してもクライアントへの影響を小さくできます。
2. 複数のクライアントから使える
APIを用意しておけば、同じ機能を複数のクライアントから利用できます。
たとえば、同じバックエンドAPIを次のように使えます。
- Webアプリ
- iOSアプリ
- Androidアプリ
- 管理画面
- 外部サービス
APIを中心に設計すると、同じビジネスロジックやデータを複数の画面・アプリで再利用しやすくなります。
3. セキュリティを管理しやすい
APIを通すことで、認証や権限チェックをサーバー側で制御できます。
たとえば、次のような制御ができます。
- ログインしていないユーザーにはデータを返さない
- 管理者だけが削除できる
- 自分のデータだけ更新できる
- 不正な入力値を拒否する
もしクライアントがデータベースに直接アクセスできてしまうと、セキュリティ上とても危険です。
APIを通すことで、安全な入口を用意できます。
4. 外部サービスと連携できる
APIを使うと、外部サービスの機能を自分のアプリに組み込めます。
たとえば、次のような連携があります。
| 外部サービス | できること |
|---|---|
| Google Maps API | 地図を表示する |
| Stripe API | 決済を行う |
| OpenAI API | AI機能を利用する |
| X API | 投稿や分析を行う |
| Slack API | メッセージを送信する |
自分ですべての機能を作らなくても、外部サービスのAPIを利用することで、高度な機能をアプリに組み込めます。
REST APIとは何か?
REST APIとは、Web APIの設計スタイルの一つです。
REST APIでは、主にHTTPメソッドとURLを使って、リソースに対する操作を表現します。
たとえば、ユーザーというリソースに対して、次のようにAPIを設計します。
GET /users
GET /users/1
POST /users
PUT /users/1
PATCH /users/1
DELETE /users/1
このように、URLで「何を対象にするか」を表し、HTTPメソッドで「何をするか」を表すのがREST APIの基本です。
ただし、REST APIを正しく理解するには、まず次の基礎知識が必要です。
- クライアントとサーバー
- リクエストとレスポンス
- HTTPメソッド
- エンドポイント
- JSON
- ステータスコード
- 認証
- API仕様
この記事で解説している内容は、REST APIを理解するための土台になります。
REST APIを学ぶ前に押さえておきたい用語まとめ
REST APIを理解する前に、最低限次の用語を押さえておくと学習しやすくなります。
| 用語 | 意味 |
|---|---|
| API | システムの機能やデータを利用するための窓口 |
| Web API | HTTP通信で利用するAPI |
| クライアント | APIを利用する側 |
| サーバー | APIを提供する側 |
| リクエスト | クライアントからサーバーへの依頼 |
| レスポンス | サーバーからクライアントへの返答 |
| エンドポイント | APIにアクセスするURL |
| HTTPメソッド | GET、POST、PUT、PATCH、DELETEなどの操作種別 |
| JSON | APIでよく使われるデータ形式 |
| ステータスコード | APIの処理結果を表す番号 |
| API仕様 | APIの使い方をまとめたルール |
APIを理解するとWeb開発がわかりやすくなる
APIを理解すると、Webアプリケーション全体の流れが見えやすくなります。
たとえば、ログイン処理を考えてみます。
1. ユーザーがメールアドレスとパスワードを入力する
2. フロントエンドがログインAPIにリクエストを送る
3. サーバーが認証処理を行う
4. 認証に成功したらトークンやユーザー情報を返す
5. フロントエンドがログイン状態として画面を切り替える
このように、画面上の操作の裏側では、APIを通じてクライアントとサーバーがやり取りしています。
APIの流れがわかると、次のようなことも理解しやすくなります。
- フロントエンドとバックエンドの役割分担
- 非同期通信
- ログイン認証
- バリデーションエラー
- データ取得
- データ更新
- REST API設計
- APIテスト
- 外部サービス連携
APIはWeb開発の中心にある考え方の一つです。
初心者がAPIでつまずきやすいポイント
APIは画面そのものではない
APIは、HTML画面を返すものとは限りません。
Web APIでは、画面ではなくJSONなどのデータを返すことが多いです。
たとえば、ブラウザでアクセスしてきれいな画面が表示されるURLもあれば、JSONだけが返ってくるAPIもあります。
{
"id": 1,
"name": "山田太郎"
}
APIは、主にプログラムから利用されることを想定した窓口です。
APIはデータベースを直接公開するものではない
APIは、データベースの中身をそのまま外部に出すものではありません。
必要なデータだけを、安全な形で返すためのものです。
たとえば、ユーザー情報を返すAPIで、パスワードや内部管理用の情報まで返してしまうのは危険です。
{
"id": 1,
"name": "山田太郎",
"email": "yamada@example.com"
}
このように、クライアントに必要な情報だけを返す設計が重要です。
APIは使う側と作る側の約束である
APIは、作る側だけの都合で決めるものではありません。
使う側が理解しやすく、間違えにくい仕様にする必要があります。
たとえば、次のような点を明確にしておくことが大切です。
- どのエンドポイントを使うのか
- どのHTTPメソッドを使うのか
- どの項目を送る必要があるのか
- どのようなレスポンスが返るのか
- エラー時はどのような形式になるのか
APIは、クライアントとサーバーの間の契約のようなものです。
まとめ
APIとは、システムの機能やデータを他のプログラムから利用するための窓口です。
Web APIでは、クライアントがサーバーにリクエストを送り、サーバーが処理結果をレスポンスとして返します。
REST APIを理解する前に、まずは次の基本を押さえておくことが大切です。
| 用語 | 役割 |
|---|---|
| クライアント | APIを使う側 |
| サーバー | APIを提供する側 |
| リクエスト | サーバーへの依頼 |
| レスポンス | サーバーからの返答 |
| エンドポイント | APIのURL |
| HTTPメソッド | 操作の種類 |
| JSON | データ形式 |
| ステータスコード | 処理結果を表す番号 |
APIを理解すると、フロントエンドとバックエンドのやり取り、ログイン処理、データ取得、外部サービス連携など、Web開発の全体像がかなり見えやすくなります。
REST APIを学ぶ前に、まずは「APIはシステム同士がやり取りするための窓口である」と理解しておくと、その後の学習がスムーズになります。

大阪のエンジニアが書いているブログ。



コメント