API

概要

APIはApplication Programming Interfaceの略で、「この形式で頼めば、この形式で返す」というプログラム同士の契約です。人間がボタンや画面（ユーザーインターフェース）を通じてソフトウェアを操作するのに対し、プログラムはAPIという窓口を通じて別のプログラムの機能を呼び出します。呼び出す側は相手の内部実装を知る必要がなく、公開された「呼び出し方」と「返ってくる形」だけを知っていればよい——この割り切りがAPIという概念の核心です。

現代のWeb開発の文脈では、APIといえばHTTPでJSONをやり取りするWeb APIを指すことがほとんどです。フロントエンドがバックエンドからデータを取るのも、自社サービスの機能を外部の開発者に開放するのも、決済や地図のような外部サービスを自分のアプリに組み込むのも、すべてAPIという語彙の上で行われます。

なぜ生まれたか

ソフトウェアが大きくなると、すべてを一枚岩で書くことは不可能になります。あるプログラムが別のプログラムの機能を使いたいとき、相手のソースコードの中身にまで依存してしまうと、相手が内部を少し変えただけでこちらが壊れる、という密結合の地獄に陥ります。そこで「内部は自由に変えてよい。ただし窓口の仕様だけは守る」という境界線を引く発想が生まれました。OSがシステムコールという形でハードウェア操作の窓口を提供したのが古典的な例で、アプリケーションはOSの内部実装を知らずにファイルやネットワークを扱えます。

インターネットの普及は、この考え方を組織の壁を越えたものにしました。2000年代、AmazonやSalesforceが自社機能をWeb API経由で外部に開放し、「サービスとサービスをネットワーク越しの契約でつなぐ」スタイルが一般化します。他社のシステムの内部を知らなくても、公開された仕様どおりにリクエストを送れば連携できる——APIはこうして、システム間分業の基本単位になりました。

詳細

契約としてのAPI

APIの本質は「インターフェース＝境界面の取り決め」です。取り決めには、呼び出しの入口（エンドポイントや関数名）、渡すべき入力（パラメータ）、返ってくる出力（レスポンスの形式）、そして失敗したときの振る舞い（エラーの表現）が含まれます。Web APIの典型的な一往復はこうなります。

呼び出す側から見えるのはリクエストとレスポンスだけで、サーバの内側で何が起きているか（どんな言語で書かれ、どんなデータベースを使っているか）は完全に隠蔽されています。この隠蔽のおかげで、提供側は契約さえ守れば内部を自由に作り変えられます。

APIの広がりと種類

「API」はWeb APIだけの言葉ではありません。プログラミング言語の標準ライブラリの関数群も、OSのシステムコールも、ブラウザがJavaScriptに提供するDOM APIも、すべてAPIです。共通するのは「実装ではなく窓口に依存する」という構造です。

Web APIの設計様式にも系譜があります。リソースをURLで表しHTTPメソッドで操作するREST APIが事実上の標準となり、その限界への応答としてGraphQL（クライアントが必要なデータの形を指定する）やgRPC（バイナリで高速に通信する）が登場しました。どれを選ぶかは、誰が使うAPIか（社外の不特定多数か、社内のサービス間か）とパフォーマンス要件で決まります。

システム設計の構成単位として

APIはアーキテクチャを語るときの共通言語でもあります。SPAはフロントエンドとバックエンドをAPIで分離する構成ですし、マイクロサービスはサービス同士がAPIだけで会話することを規律とする設計です。逆に言えば、APIの境界の引き方を間違えると、サービスを分けたのに互いの内部事情に依存し合う「分散モノリス」が生まれます。境界設計こそがAPI設計の本丸です。

実務での勘所

実務でAPIを提供する側に回ると、機能そのものより「契約の維持」に労力を割くことになります。一度公開したAPIの仕様を変えると利用者のコードが壊れるため、後方互換性を保つか、/v1 /v2 のようなバージョニングで移行期間を設けるのが定石です。また、外部に開放するAPIには認証・認可（APIキーやOAuth）、流量制限（レートリミット）、仕様書（OpenAPIなどのスキーマ定義）が事実上必須です。仕様書をコードから自動生成したり、逆にスキーマを起点に開発を進めるスキーマ駆動開発は、フロントとバックの分業を円滑にする現代的なプラクティスです。