Web APIは、異なるソフトウェアやサービスをインターネット経由で接続するための標準的な「窓口」であり、現代のアプリケーション開発において不可欠な技術基盤です。
Web APIの基本的な概念と歴史、仕組み、構成要素について整理するセクションです。
Web APIは「インターネット越しに機能やデータを公開・利用するための標準インターフェース」であり、異なる技術スタックのシステム同士を疎結合につなぐ役割を担います。
Web API(Web Application Programming Interface)は、異なるソフトウェアやサービス同士をインターネット経由で接続し、情報や機能のやりとりを行うための「窓口」です。HTTPなどのWeb技術を応用し、ネットワークを通じて他のプログラムから利用できる仕組みとして設計されています。クライアント(例: スマートフォンアプリやWebサイト)からのリクエストに対し、サーバーが必要なデータや処理結果を返却します。これにより、アプリケーション開発の効率化や柔軟な機能拡張、他システムとの容易な連携が実現されています。
用語
| 用語 | 説明 |
|---|---|
| API | Application Programming Interface。ソフトウェア同士が機能・データをやりとりするための取り決め |
| Web API | HTTPを通信プロトコルとして利用するAPIの総称 |
| クライアント | APIを呼び出す側。スマートフォンアプリ・Webブラウザ・別サーバーなどが該当 |
| サーバー | APIリクエストを受け取り処理・応答を返す側 |
| エンドポイント | APIが公開する特定のURL。操作対象リソースごとに定義される |
参考
APIの概念自体は1990年代のOS・デスクトップ連携に端を発し、インターネットの普及とともにWeb APIへと進化。2000年代以降のモバイル・クラウド革命が普及を決定づけました。
API自体の歴史は古く、OSやデスクトップアプリケーション間で機能を共通利用する仕組みとして1990年代頃から使われてきました。インターネットとWeb技術の普及に伴い、HTTP通信を窓口として機能やデータをネットワーク経由で提供できる「Web API」が登場しました。2000年代初頭にはAmazon、Salesforce、eBayなどが商用Web APIの提供を開始し、アプリケーションやサービスの外部連携が容易になりました。モバイルアプリやクラウドサービスの拡大に合わせてWeb APIは急速に一般化し、現在ではあらゆる分野で標準的な技術となっています。
| 時代 | 出来事 |
|---|---|
| 1990年代 | OS・デスクトップ間のAPI連携が普及(Windows API など) |
| 2000年代初頭 | Amazon・Salesforce・eBayが商用Web APIを提供開始 |
| 2000年代後半〜 | RESTの台頭、Twitterなどソーシャル系APIが爆発的に拡大 |
| 2010年代〜 | モバイルアプリ・クラウドの普及でWeb APIが事実上の標準に |
| 現在 | GraphQL・gRPC・WebSocketなど多様なAPI形式が共存 |
💡 ポイント: 初期の商用Web APIはSOAPやXML-RPCベースでしたが、よりシンプルなREST設計が台頭し現在の主流となっています。
クライアントが指定したエンドポイント・メソッド・パラメータをもとにサーバーが処理し、JSON/XMLで結果を返す「リクエスト/レスポンス」サイクルがWeb APIの核心です。
Web APIは主に「クライアント」と「サーバー」がネットワーク(HTTP/HTTPS)を通してリクエストとレスポンスをやりとりすることで動作します。クライアント側はAPIサーバーが公開しているエンドポイント(特定のURL)に対して、必要なパラメータやメソッド(GET、POST、PUT、DELETEなど)を指定してリクエストを送信します。サーバー側はそのリクエストを受け取り、あらかじめ定められたルール(API仕様書)に基づいて処理し、応答(レスポンス)を返します。レスポンスは主にJSONやXML形式のデータで返されるため、異なるアプリケーション間でも互換性を持ってやり取りできるのが特徴です。
クライアント サーバー
│ │
│── GET /users/123 ──────────────► │
│ Headers: Authorization: Bearer │
│ │ 処理(DBアクセスなど)
│◄── 200 OK ────────────────────── │
│ Body: {"id":123,"name":"..."} │
│ │
HTTPメソッドとCRUD操作の対応
| HTTPメソッド | CRUD操作 | 主な用途 |
|---|---|---|
| GET | Read | リソースの取得 |
| POST | Create | リソースの新規作成 |
| PUT / PATCH | Update | リソースの更新(全体 / 部分) |
| DELETE | Delete | リソースの削除 |
代表的なHTTPステータスコード
| コード | 意味 | 説明 |
|---|---|---|
| 200 | OK | リクエスト成功 |
| 201 | Created | リソース新規作成成功 |
| 400 | Bad Request | リクエスト内容の誤り |
| 401 | Unauthorized | 認証が必要または失敗 |
| 403 | Forbidden | 権限不足でアクセス拒否 |
| 404 | Not Found | リソースが存在しない |
| 500 | Internal Server Error | サーバー内部エラー |
// レスポンスボディのJSON例
{
"id": 123,
"name": "山田 太郎",
"email": "yamada@example.com",
"createdAt": "2024-01-15T09:00:00Z"
}
💡 ポイント: HTTPSの利用は現在の標準。通信の暗号化により、APIキーや個人情報の盗聴を防止します。
Web APIは「エンドポイント・メソッド・パラメータ・レスポンス・ステータスコード・認証」の6要素で構成され、それぞれが役割分担して安全・確実なデータ交換を実現します。
Web APIは以下の主要な構成要素から成り立っています:
| 要素 | 説明 |
|---|---|
| エンドポイント | APIが公開するURL。リソースごとに異なる(例: /users, /products/42) |
| HTTPメソッド | 操作種別(GET, POST, PUT, PATCH, DELETE など) |
| リクエストパラメータ・ヘッダ | クライアントが指定する入力データや制御情報(クエリ文字列・リクエストボディ・Authorizationヘッダなど) |
| レスポンスボディ | サーバーが返却する実際のデータ(JSON や XML が主流) |
| ステータスコード | サーバーがリクエストの処理結果を表す3桁の番号(2xx: 成功、4xx: クライアントエラー、5xx: サーバーエラー) |
| 認証・認可 | APIキー・OAuth2トークン・JWT など、アクセス制御手法 |
主な認証・認可方式
| 方式 | 概要 | 主な用途 |
|---|---|---|
| APIキー | リクエストヘッダやクエリに固定の秘密キーを付与 | 社内API・シンプルな公開API |
| OAuth 2.0 | 認可サーバーが発行するアクセストークンを利用 | 外部サービス連携・ユーザー代理アクセス |
| JWT | 署名付き自己完結トークン。サーバー側でセッション管理不要 | マイクロサービス間通信・SPA認証 |
| Basic認証 | ID/パスワードをBase64エンコードして送付(HTTPS必須) | 開発環境・内部ツール |
💡 ポイント: APIキーは漏洩すると即座に悪用リスクが生じるため、環境変数や秘密管理サービス(AWS Secrets Manager など)での管理が推奨されます。
APIは「誰に公開するか」によってパブリック・パートナー・プライベートの3種に分類され、それぞれ公開範囲・認証強度・ガバナンス要件が異なります。
APIは提供や利用の範囲によって次のように分類されます:
| 種別 | 公開範囲 | 認証の厳格度 | 代表例 |
|---|---|---|---|
| パブリックAPI | 誰でも利用可 | 低〜中(APIキー程度) | Twitter API, OpenWeather API |
| パートナーAPI | 契約・提携先のみ | 中〜高(OAuth, IP制限など) | 決済系API(Stripe Connect)、物流連携API |
| プライベートAPI(内部API) | 自社システム内のみ | 高(VPN, mTLSなど) | 社内マイクロサービス間通信、バックオフィスシステム連携 |
💡 ポイント: プライベートAPIであっても、将来のパートナー化・公開化を見据えて設計段階からOpenAPIなどで仕様を文書化しておくと移行コストを削減できます。