アプリケーションプログラミングインタフェース

アプリケーションプログラミングインタフェース（英: application programming interface, API）とは、コンピュータ間やコンピュータプログラム間の接続である。他のソフトウェアにサービスを提供するソフトウェアインタフェースの一種である。そのような接続やインタフェースを構築する方法を説明したドキュメントや標準は、API仕様（API specification）と呼ばれる。この標準を満たすコンピュータシステムは、APIを「実装する（implement）」または「公開する（expose）」と表現される。APIという用語は、仕様と実装のどちらを指す場合もある。

コンピュータと人を繋ぐユーザインタフェースとは対照的に、アプリケーションプログラミングインタフェースはコンピュータやソフトウェア同士を繋ぐものである。ソフトウェアを開発するコンピュータプログラマ以外の人間（エンドユーザー）が直接使用することを意図したものではない。APIは多くの場合、プログラマが利用できるツールやサービスとして機能する様々な部分から構成される。これらの部分のいずれかを使用するプログラムやプログラマは、APIのその部分を「呼び出す（call）」と言われる。APIを構成する呼び出しは、サブルーチン、メソッド、リクエスト、またはエンドポイントとも呼ばれる。API仕様はこれらの呼び出しを「定義」しており、つまり、その使用方法や実装方法を説明しているということである。

APIの主な目的の一つは、システムがどのように機能するかという内部の詳細を隠蔽し、プログラマにとって有用な部分のみを公開し、後に内部の詳細が変更されたとしても一貫性を保つことである。APIは、特定のシステムのペアのためにカスタム構築される場合もあれば、多くのシステム間で相互運用性を可能にする共有標準である場合もある。

APIという用語は、インターネットで接続されたコンピュータ間の通信を可能にするWeb APIを指すためによく使用される。また、プログラミング言語、ソフトウェアライブラリ、コンピュータのオペレーティングシステム、およびコンピュータ・ハードウェア向けのAPIも存在する。APIは1940年代に起源を持つが、この用語自体は1960年代や70年代になるまで登場しなかった。

概要

APIは、ソフトウェアシステムを外部からのやり取りに対してオープンにする。あらかじめ定められたルールや信号を使用して、境界（インタフェース）を越えて2つのソフトウェアシステムが通信することを可能にする。言い換えれば、APIはソフトウェアのエンティティ同士を接続するものである。ユーザインタフェースとは異なり、APIは通常、ユーザーには見えない。ソフトウェアシステムの「裏側」として機能し、機械間の通信に使用される。

うまく設計されたAPIは、ソフトウェアやソフトウェア開発者が必要とするオブジェクトやアクションのみを公開し、不要な詳細は隠蔽する。この抽象化によりプログラミングが簡素化される。

APIは、ソフトウェアを繋ぎ合わせることから、ブロック玩具に例えられる

APIを使用してソフトウェアを構築することは、レゴブロックのようなブロック玩具に例えられる。ソフトウェアサービスやソフトウェアライブラリはブロックに例えられ、それらはAPIを介して結合され、新しいソフトウェア製品を構成することができる。結合するプロセスは「統合（integration）」と呼ばれる。

一例として、APIを提供する気象センサーを考えてみる。特定のメッセージがセンサーに送信されると、現在の気象条件を検出し、天気予報を返す。センサーをアクティブにするメッセージはAPIの「呼び出し（call）」であり、天気予報はAPIの「応答（response）」である。天気予報アプリは多くの気象センサーAPIと統合し、地理的領域全体から気象データを収集するかもしれない。

APIはしばしば契約に例えられる。APIを提供するサービスプロバイダと、それに依存するソフトウェア開発者との間の合意を表す。APIが安定している場合、または予測可能な方法でのみ変更される場合、開発者のAPIに対する信頼は高まる。これにより、APIの使用が増加する可能性がある。

APIの種類

ライブラリとフレームワーク

ソフトウェアライブラリへのインタフェースは、APIの一種である。APIは「期待される動作」（仕様）を記述・規定するのに対し、ライブラリはこの一連のルールの「実際の実行」である。

単一のAPIは、同じプログラミングインタフェースを共有する様々なライブラリの形で、複数の実装を持つことができる（または抽象的な定義のみで実装を持たないこともある）。

APIをその実装から分離することで、ある言語で書かれたプログラムが別の言語で書かれたライブラリを使用できるようになる。例えば、ScalaとJavaは互換性のあるバイトコードにコンパイルされるため、Scalaの開発者は任意のJava APIを利用することができる。

APIの使用は、関係するプログラミング言語の種類によって異なる場合がある。 Luaなどの手続き型言語のAPIは、主にコードの実行、データの操作、エラーの処理を行うための基本的なルーチンで構成されるのに対し、Javaなどのオブジェクト指向言語のAPIは、クラスとクラスメソッドの仕様を提供する。ハイラムの法則は、「APIのユーザー数が十分に多ければ、契約で何を約束しようと関係ない。システムの観測可能なすべての動作は、 誰かが依存するようになる」と述べている。その一方で、APIを使用するほとんどのアプリケーションは、APIのわずかな部分しか使用しない傾向があることをいくつかの研究が示している。

言語バインディングもAPIである。ある言語の特徴や機能を別の言語で実装されたインタフェースにマッピングすることで、ある言語で書かれたライブラリやサービスを別の言語での開発時に使用できるようにする。SWIGやF2PY（FORTRANからPythonへのインタフェースジェネレータ）などのツールは、そのようなインタフェースの作成を容易にする。

APIはソフトウェアフレームワークに関連することもある。フレームワークはいくつかのAPIを実装するいくつかのライブラリに基づいて構築できるが、 通常のAPIの利用とは異なり、フレームワークに組み込まれた動作へのアクセスは、フレームワーク自体に新たなクラスを組み込み、機能を拡張することによって行われる。

さらに、プログラムの全体的な制御フローは、呼び出し元の制御を離れ、制御の反転（IoC）などのメカニズムにより、フレームワーク側に委ねられることがある。

オペレーティングシステム

APIは、アプリケーションとオペレーティングシステムとの間のインタフェースを指定することができる。例えばPOSIXは、POSIX準拠のオペレーティングシステム用に書かれたアプリケーションが、別のPOSIX準拠のオペレーティングシステム用にコンパイルできるようにすることを目的とした一連の共通APIを指定している。

LinuxやBerkeley Software Distributionは、POSIX APIを実装するオペレーティングシステムの例である。

マイクロソフトは、特にWindows API（Win32）ライブラリ内で、下位互換性のあるAPIを強く重視してきたため、古いアプリケーションは「互換モード」と呼ばれる実行ファイル固有の設定を使用して新しいバージョンのWindows上で実行できる場合がある。開発者が自社のオペレーティングシステムの内部APIにアクセスできることがどれほどの利点をもたらしているかは明確ではない。1987年のTechnologic Computer Letterのリチャード・A・シェイファーは、この状況を「マイクロソフトがすべてのバットとフィールドを所有している」野球の試合に例えた。また、ロータス・デベロップメントやアシュトンテイトなどの大規模ベンダーは、小規模なソフトウェア開発者が得られなかったMS-DOS 5.0に関する情報を受け取ったと報告されている。しかし、アシュトン・テイトのエド・エスバーは、1987年のビル・ゲイツへのインタビューで、マイクロソフトの開発者でさえ初期のAPIに基づいてソフトウェアを書き直すべきだと聞いたと語った。ゲイツはそのインタビューで、マイクロソフトのMacintoshアプリケーションがMS-DOS用よりも成功したのは、同社がMac OSにリソースを割く必要がなかったためだと指摘した。

APIはソースコードベースであるのに対し、ABI（アプリケーションバイナリインタフェース）はバイナリベースであるという点で異なる。例えば、POSIXがAPIを提供するのに対し、Linux Standard BaseはABIを提供する。

リモートAPI

リモートAPIを使用すると、開発者は通信プロトコル（言語やプラットフォームに関係なく、さまざまなテクノロジが連携できるようにする特定の通信標準）を通じてリモートリソースを操作できる。 例えば、Java Database Connectivity APIを使用すると、開発者は同じ関数のセットを使用して様々な種類のデータベースにクエリを実行できる。一方、Java Remote Method Invocation APIは、Java Remote Method Protocolを使用して、リモートで動作する関数を呼び出すことができるが、開発者にはローカルにあるかのように扱える。

したがって、リモートAPIは、オブジェクト指向プログラミングにおけるオブジェクト抽象化を維持するのに役立つ。プロキシオブジェクト上でローカルに実行されるメソッド呼び出しは、リモートプロトコルを使用してリモートオブジェクト上の対応するメソッドを呼び出し、ローカルで戻り値として使用される結果を取得する。プロキシオブジェクトに対する変更は、リモートオブジェクトにも反映される。

Web APIと様式

→詳細は「Web API」を参照

APIは通常、Web開発で使用される場合、Hypertext Transfer Protocol（HTTP）リクエストメッセージなどの仕様のセットと、拡張マークアップ言語（XML）またはJavaScript Object Notation（JSON）形式などの応答メッセージの構造の定義を指す。

例えば、eコマースサイトにおいて、開発者が自ら配送料金表をデータベースに登録しなくても、現在の配送料金を自動で計算・追加し、配送注文を容易にする「配送会社のAPI」などが挙げられる。

「Web API」は歴史的にWebサービスとほぼ同義であったが、Web 2.0では、SOAPベースのWebサービスやサービス指向アーキテクチャ（SOA）から離れ、より直接的なRESTスタイルのWebリソースやリソース指向アーキテクチャ（ROA）へと向かっている。この傾向の一部は、Webベースのオントロジー工学技術を促進する概念であるResource Description Framework（RDF）に向けたセマンティック・ウェブの動きに関連している。Web APIにより、複数のAPIを組み合わせてマッシュアップと呼ばれる新しいアプリケーションを作成できる。 ソーシャルメディアの分野では、Web APIによりWebコミュニティがコンテンツやデータをコミュニティやアプリケーション間で共有しやすくなった。このようにして、ある場所で動的に作成されたコンテンツを、Web上の複数の場所に投稿および更新できる。例えば、TwitterのREST APIにより、開発者はコアなTwitterデータにアクセスでき、Search APIは開発者がTwitterの検索やトレンドデータと対話するためのメソッドを提供する。

WebAPIは様々なスタイルで表現される。例えばリソースの表現は以下の様式がありうる。

パスは厳密な階層構造をもつリソースの表現に適している。クエリ文字列およびリクエストボディは自由な表現が可能なため任意のリソースに利用できる。

広く知られるWebAPIスタイルの例として以下が挙げられる。

言語束縛とインタフェースジェネレータ

複数の高水準言語での使用を意図したAPIは、文法的・意味的に各言語に適したインタフェースをAPIに自動的にマッピングする機能を提供している。これを言語束縛と呼び、それ自体もAPIである。その目的は、APIに必要な機能の大部分をカプセル化する「薄い層（ラッパー）」を各言語向けに提供することである。

以下に挙げたものは、コンパイル時に言語とAPIの束縛を行うインタフェースジェネレータである。

設計

APIの設計は、その使用方法に大きな影響を与える。情報隠蔽の原則は、モジュールのユーザーがモジュール内部の複雑さを理解する必要がないように、モジュールの実装詳細を隠蔽することによってモジュールプログラミングを可能にするプログラミングインタフェースの役割を説明している。したがって、APIの設計は、ユーザーが期待するツールのみを提供することを目指す。プログラミングインタフェースの設計は、複雑なソフトウェアの構成であるソフトウェアアーキテクチャの重要な部分を表している。

互換性の管理と運用

APIは公開された呼び出し口の集合であるだけでなく、利用者が依拠してよい振る舞いの境界を定める契約でもある。利用側が内部実装や文書化されていない挙動に依存すると、提供側の更新時に互換性が失われやすいため、安定性は公開仕様に明示された範囲に基づいて判断される。

公開APIを提供する側は、互換性のある小さな拡張（マイナーアップデート）と、内部インタフェースや未公開仕様に依存した互換性のない変更（メジャーアップデート）を区別し、並行提供や非推奨化の予告などで移行を管理することが多い。例えば、Microsoft Graphは旧版を廃止の少なくとも24か月前に非推奨とし、Google Cloud Endpointsでは互換性のない変更時にメジャー版を上げて複数メジャー版を並行提供している。このように、APIの設計・公開・廃止は、単なる関数一覧の提示ではなく、長期的な利用可能性を管理する運用上の課題でもある。

インタフェース定義とOpenAPI

特にWeb APIにおいては、OpenAPI Specificationのような機械可読な記述形式でインタフェースを定義することが普及している。OpenAPI Specificationは、HTTP APIの機能を、人間とコンピュータの双方がソースコードや追加文書なしに理解できるようにする標準的な記述であり、文書生成、サーバ・クライアントコード生成、テストなどにも利用できる。日本の公的APIでも、デジタル庁が氏名突合支援サービスのAPI仕様をOpenAPI SpecificationのYAML文書として公開するなど活用例がある。

APIドキュメント

APIドキュメントは、APIが提供するサービスとそのサービスの使用方法を説明し、利用者（クライアント）が実践的に知っておくべきすべての情報を網羅することを目指している。

ドキュメントは、APIを使用するアプリケーションの開発と保守に不可欠である。 APIドキュメントは従来、ドキュメントファイルとして提供されるのが一般的だが、ブログ、フォーラム、Q&Aウェブサイトなどのソーシャルメディアで共有されることもある。

従来のドキュメントファイルは、一貫した外観と構造を持つJavadocやPydocなどのドキュメントシステムを介して提示されることが多い。ただし、ドキュメントに含まれるコンテンツの種類はAPIによって異なる。

より分かりやすくするために、APIドキュメントにはAPI内のクラスとメソッドの説明だけでなく、典型的な使用シナリオ、コードスニペット、設計の根拠、パフォーマンスに関する議論、契約などが含まれる場合があるが、APIサービス自体の実装詳細は通常省略される。指示文書、チュートリアル、リファレンス作品など、さまざまな形をとることができる。また、ガイドや機能を含むさまざまな種類の情報も含まれる。

APIの使用方法に関する制限や制約もドキュメントでカバーされる。例えば、API関数のドキュメントでは、そのパラメータをnullにできないこと、関数自体がスレッドセーフではないことなどが記述される場合がある。APIドキュメントは包括的になる傾向があるため、執筆者がドキュメントを最新の状態に保つことや、ユーザーが注意深く読むことは課題であり、バグを生み出す可能性がある。

APIドキュメントは、Javaアノテーションなどのメタデータ情報で充実させることができる。このメタデータは、コンパイラ、ツール、および「ランタイム」環境によって使用され、カスタム動作やカスタム処理を実装することができる。

データ駆動型の方法でAPIドキュメントを生成することが可能である。特定のAPIを使用する多くのプログラムを観察することで、典型的な使用法、ならびに必要な契約やディレクティブを推論することができる。そして、テンプレートを使用して、マイニングされたデータから自然言語を生成できる。

セキュリティ

APIを利用するシステムにおいて、APIキーやシークレットトークンなどの認証情報は、システムが正当な利用者であることを証明する重要なデータである。これが悪意のある第三者に漏洩した場合、不正アクセス、データの改ざん・漏洩、または意図しない高額なクラウドリソース利用料の請求などの被害が生じる可能性がある。

認証情報の保護

ソースコード内にAPIキーを直接記述する「ハードコーディング」は、セキュリティ上禁忌とされている。これを防ぐため、認証情報をソースコードから完全に分離し、.envファイルなどの環境変数を通じて外部から動的に読み込む手法が用いられる。また、この運用においては、環境変数を記述したファイルをGitなどのバージョン管理システムに含めないよう、.gitignore等を利用して管理対象から除外することが必須となる。仮にGitHubなどの公開リポジトリに認証情報が誤ってプッシュされた場合、悪意のある巡回ボットによって数秒から数分以内に検知され、即座に不正利用されるリスクが存在する。

さらに、より強固なセキュリティが求められる本番環境においては、単なるファイルによる管理から脱却し、AWS Secrets Manager、Google Cloud Secret Manager、Azure Key Vaultなどのシークレット管理サービスを活用し、認証情報を暗号化した上でより安全に一元管理する。

アーキテクチャの設計

システムの設計段階から、APIキーの露出を構造的に防ぐ手法が推奨されている。例えば、Webブラウザ上で動作するフロントエンド（JavaScriptフレームワーク等）やモバイルアプリケーションから直接外部APIを呼び出す設計とした場合、クライアント側にAPIキーが完全に露出してしまうという問題が生じる。これを防ぐため、クライアントから直接外部へリクエストを送るのではなく、一度自社のバックエンドサーバーやBFF（Backends For Frontends）を経由させ、そこでAPIキーを付与して要求を中継する設計とするのが一般的である。また、通信経路だけでなく、システムが内部で出力するデータに対する配慮も不可欠である。エラー調査などの目的で記録されるシステムログに対して、APIキーやユーザーの個人情報が誤って平文のまま保存されることによる情報漏洩を防ぐため、システム実行時にそれらの機密データを自動的に検知し、適切なマスキングを施す処理を組み込むことが求められる。

最小特権の原則に基づく制限

APIキーが漏出した際、被害範囲を制限するため、APIキーに付与する権限について「最小権限の原則」に基づいた運用が推奨されている。例えば、データの参照のみを行うシステムであれば、書き込みや削除の権限を持たない読み取り専用のキーを発行して運用する。それに加え、APIプロバイダーの設定で、自社のサーバーなどの特定のIPアドレスや、特定のドメインからのリクエストのみを許可するようアクセス元を制限する。

利用上限の設定

APIの呼び出し回数やクラウドリソースの請求額に対して論理的な利用上限（クォータ）を設定し、常時監視する仕組みを組み込むことが推奨されている。利用量が一定のしきい値に達した際に管理者に自動でアラートを通知、あるいは一時停止する設定をしておくことで、DDoS攻撃や第三者の不正利用に伴う被害を最小化することができる。

キーのローテーション

特定のAPIキーを長期間使い続けることは漏出のリスクを増大させることになる。定期的に新しいキーを発行し、古いキーを無効化し、キーをローテーションする運用が推奨されている。

暗号化通信

通信経路上での中間者攻撃やパケット盗聴を防ぐため、APIエンドポイントとの通信には常にHTTPS/TLSを使用する。

リリース方針

APIは、テクノロジー企業が他のシステムと連携するための一般的な方法の1つである。APIを提供および使用する企業は、ビジネスエコシステムのメンバーと見なされる。

APIをリリースするための主な方針は次のとおりである。

パブリックAPIの意味合い

APIが公開される際の重要な要因は、その「インタフェースの安定性」である。APIへの変更（関数呼び出しに新しいパラメータを追加するなど）は、そのAPIに依存するクライアントとの互換性を壊す可能性がある。

公開されたAPIの一部が変更される可能性があり、まだ安定していない場合、特定のAPIのそのような部分は明示的に「不安定」として文書化されるべきである。例えば、Google Guavaライブラリでは、不安定と見なされ、すぐに変更される可能性のある部分は、Java・アノテーションの @Beta でマークされる。

パブリックAPIは、その一部を非推奨（deprecated）または取り消しとして宣言することがある。これは通常、APIのその部分が削除される候補、または下位互換性のない方法で変更される候補と見なされるべきであることを意味する。したがって、これらの変更により、開発者は将来削除されたりサポートされなくなったりするAPIの部分から移行できるようになる。

開発者の書くコードには、API設計者の意図しない革新的、あるいは場当たり的な使い方が含まれることがある。つまり、かなりのユーザーベースを持つライブラリの場合、ある要素がパブリックAPIの一部になると、多様な方法で使用される可能性がある。 2020年2月19日、Akamaiは年次の「インターネットの現状」レポートを発表し、サイバー犯罪者が世界中の金融サービスのパブリックAPIプラットフォームを標的にしているという増大する傾向を示した。2017年12月から2019年11月にかけて、Akamaiは854億2000万件の認証情報違反攻撃を目撃した。約20%、つまり 165億5000万件は、APIエンドポイントとして定義されたホスト名に対する攻撃であった。このうち、4億7350万件が金融サービス部門の組織を標的としていた。

APIの著作権保護をめぐる紛争

アメリカ国内

2010年、米オラクルはGoogleがJavaの新たな実装をAndroidの一部として配布したとして、Googleを提訴した。Googleは、同様のOpenJDKプロジェクトには許可が与えられていたものの、Java APIを複製する許可を得ていなかった。『Oracle対Google』の訴訟において、ウィリアム・アルスプ判事は、米国ではAPIを著作権で保護することはできず、オラクルを勝訴させれば、著作権保護の対象が「機能的な記号のセット」へと大幅に拡大され、単純なソフトウェアコマンドの著作権保護まで認めることになるとの判決を下した。

オラクルの主張を受け入れることは、あるコマンドシステムを実行する特定のコードの著作権を認め、他の者が同じコマンドを実行するための別のコードを書くことまで禁じる結果を招くことになる。

アルスプの判決は、2014年の連邦巡回区控訴裁判所への上訴で覆されたが、APIの利用がフェアユースに該当するかどうかという問題は未解決のままであった。

2016年、2週間の裁判の後、陪審員はGoogleによるJava APIの再実装がフェアユースを構成すると判断したが、オラクルはこの決定に対して控訴する意向を示した。オラクルは控訴審で勝訴し、連邦巡回区控訴裁判所はGoogleのAPIの使用はフェアユースに該当しないとの判決を下した。2019年、Googleは著作権の有無とフェアユースの該当性に関する両方の判決を不服としてアメリカ合衆国最高裁判所に上訴し、最高裁は審理を承認した。COVID-19パンデミックのため、この訴訟の口頭弁論は2020年10月まで延期された。2021年、最高裁はAPIに著作権があってもフェアユースとして利用可能であるとの最終判断を下した。。

日本国内

日本においては、著作権法第10条第3項において、プログラムのインタフェースやプロトコルが著作物とみなされないことが明確に示されている。

他

互換性のあるAPIを作成する目的で、既存のAPIの実装を解析することは一般的に合法とされている。。この手法は相互運用性のためのリバースエンジニアリングと呼ばれる。

類似する概念

特にDDIやファームウェアインタフェースを使う場合は、ソフトウェアがアプリケーションとは異なる環境で動作し、OSのAPIに依存するライブラリが使用できない場合もあるため、開発者はどのインターフェースを使用しているかを意識する必要がある。

歴史

APIの概念を単なるアプリケーションプログラムの枠を超え、一般的なプログラミングインターフェースへと拡張することを提案した1978年の図

当初、APIという用語はエンドユーザー向けプログラム（アプリケーションプログラム）専用のインターフェースを指す言葉であった。この名残は、「アプリケーションプログラミングインタフェース」という名称そのものに表れている。今日ではその意味が広がり、ユーティリティソフトウェアやハードウェアインターフェースまでも含まれるようになっている。。

APIという概念自体は、用語が生まれるよりもはるかに歴史が古い。イギリスのコンピュータ科学者モーリス・ウィルクスとデビッド・ホイーラーは、1940年代に初期のコンピュータであるEDSAC用のモジュール式ソフトウェアライブラリに取り組んだ。このライブラリのサブルーチンは、書類整理キャビネットに整理されたさん孔テープに保存されていた。このキャビネットには、ウィルクスとホイーラーが「ライブラリカタログ」と呼んだ、各サブルーチンとそれをプログラムに組み込む方法についてのメモも含まれていた。今日では、このようなカタログはプログラマが必要とする各サブルーチンの使用（または「呼び出し」）方法を指示するため、API（またはAPI仕様、APIドキュメント）と呼ばれるだろう。

ウィルクスとホイーラーの著書『The Preparation of Programs for an Electronic Digital Computer』には、公開された最初のAPI仕様が含まれている。ジョシュア・ブロックは、APIは発明されるというよりも発見される概念に近いため、ウィルクスとホイーラーがAPIを「実質的にに発明した」と見なしている。

APIという用語を作った人々はUnivac 1108でソフトウェアを実装していたが、彼らのAPIの目的は、ハードウェア非依存のプログラムを可能にすることであった。

「アプリケーションプログラムインタフェース」（-ingという接尾辞なし）という用語は、1968年のAFIPS会議で発表された『Data structures and techniques for remote computer graphics』と呼ばれる論文に初めて記録されている。この論文の著者は、アプリケーション（この場合はグラフィックスプログラム）とコンピュータシステムの残りの部分との相互作用を説明するためにこの用語を使用している。一貫したアプリケーションインターフェース（Fortranのサブルーチン呼び出しで構成）により、プログラマをグラフィックス機器特有の仕様への対応から解放し、機器が交換された場合でもハードウェアの独立性を保つことを目的としていた。。

この用語は、1974年の『The Relational and Network Approaches: Comparison of the Application Programming Interface』という論文で、C. J. Dateによってデータベースの分野に導入された。APIは、データベース管理システムのためのANSI/SPARCフレームワークの一部となった。このフレームワークは、アプリケーションプログラミングインタフェースを、クエリインタフェースなどの他のインタフェースとは別に扱った。1970年代のデータベース専門家は、これらの異なるインタフェースを組み合わせることができると観察した。 高度で充実したアプリケーションインターフェースであれば、他のインターフェースもサポートできると考えたからである。

この観察により、アプリケーションプログラミングだけでなく、すべてのタイプのプログラミングをサポートするAPIが生まれた。1990年には、技術者のカール・マラマッドによって、APIは単に「特定のタスクを実行するためにプログラマが利用できる一連のサービス」と定義されるに至った。。

NASAによって書かれたWeb APIドキュメントのスクリーンショット

APIのアイデアは、遠隔手続き呼出しやWeb APIの登場により再び拡張された。1970年代と80年代にコンピュータネットワークが一般的になると、プログラマはローカルのコンピュータだけでなく、遠隔地のコンピュータ上にあるライブラリも呼び出したいと考えた。これらの遠隔手続き呼出しは、特にJava言語でよくサポートされていた。1990年代には、インターネットの普及に伴い、CORBA、COM、DCOMなどの標準がAPIサービスを公開する最も一般的な方法となるために競い合った。

2000年のカリフォルニア大学アーバイン校でのロイ・フィールディングの博士論文『Architectural Styles and the Design of Network-based Software Architectures』では、Representational state transfer (REST)が概説され、フィールディングが従来の「ライブラリベース」のAPIと対比させた「ネットワークベースのアプリケーションプログラミングインタフェース」のアイデアが説明された。XMLとJSONのWeb APIは2000年から広く商業的に採用され始め、2021年現在も続いている。Web APIは現在、APIという用語の最も一般的な意味となっている。

2001年にティム・バーナーズ＝リーによって提案されたセマンティック・ウェブには、APIをソフトウェアの動作インタフェースではなく、オープンで分散型のデータインタフェースとして再構築する「セマンティックAPI」が含まれていた。結果的にオープンなものよりも独自仕様の（プロプライエタリな）インターフェースやエージェントの方が広く普及したが、データインタフェースとしてのAPIのアイデアは定着した。Web APIはオンラインであらゆる種類のデータを交換するために広く使用されているため、APIはインターネット上の通信の大部分を表現する広範な用語となっている。このように使用される場合、APIという用語は通信プロトコルという用語と意味的に重なる部分がある。

APIの例

脚注

[脚注の使い方]

注釈

出典

  1. ↑ 「インターフェイス」「インターフェース」と表記されることもあるが、本記事では「インタフェース」で統一する。
  2. ↑ Brian E. Perron; Hui Luan; Zia Qi; Bryan G. Victor; Kavin Goyal (2024). “Demystifying Application Programming Interfaces (APIs): Unlocking the Power of Large Language Models and Other Web-based AI Services in Social Work Research”. arXiv (Cornell University) 2026年8月19日閲覧。.
  3. 1 2 Reddy, Martin (2011) (英語). API Design for C++. Elsevier Science. ISBN 978-0-12-385004-1
  4. 1 2 “Intro to APIs: History of APIs”. Postman. 2026年8月19日閲覧。
  5. 1 2 Pedro, Bruno (2024) (英語). Building an API Product: Design, Implement, Release, and Maintain API Products that Meet User Needs. Packt Publishing. ISBN 978-1-83763-853-6
  6. ↑ Biehl, Matthias (2016) (英語). RESTful API Design. API-University Press. ISBN 978-1-5147-3516-9
  7. 1 2 3 “Measuring API Usability”. Dr. Dobb's. 2026年8月19日閲覧。
  8. ↑ Jin, Brenda (2018) (英語). Designing Web APIs: Building APIs That Developers Love. O'Reilly Media. ISBN 978-1-4920-2687-7
  9. ↑ Geewax, JJ (2021) (英語). API Design Patterns. Manning. ISBN 978-1-63835-033-0
  10. ↑ Jacobson, Daniel (2011) (英語). APIs: A Strategy Guide. O'Reilly Media. ISBN 978-1-4493-2164-2
  11. ↑ “Combining Scala and Java”. Artima. 2026年8月19日閲覧。
  12. ↑ The design and implementation of a language for extending applications. XXI Brazilian Seminar on Software and Hardware (英語). 1994. 2026年8月19日閲覧.
  13. ↑ “Just what is the Java API anyway?”. JavaWorld. 2026年8月19日閲覧。
  14. ↑ Winters, Titus (2020) (英語). Software engineering at Google: lessons learned from programming over time. O'Reilly Media. ISBN 978-1-4920-8279-8
  15. ↑ Use at your own risk: the Java unsafe API in the wild. OOPSLA 2015 (英語). 2015. 2026年8月19日閲覧.
  16. ↑ “Standards, APIs, Interfaces and Bindings”. ACM. 2026年8月19日閲覧。
  17. ↑ “F2PY.org”. F2PY.org. 2026年8月19日閲覧。
  18. ↑ “Inversion Of Control”. Martin Fowler. 2026年8月19日閲覧。
  19. ↑ “Object-Oriented Application Frameworks”. Vanderbilt University. 2026年8月19日閲覧。
  20. ↑ Lewine, Donald A. (1991) (英語). POSIX Programmer's Guide. O'Reilly & Associates, Inc.. ISBN 978-0-937175-73-6
  21. ↑ Joel West; Jason Dedrick (2001). “Open source standardization: the rise of Linux in the network era”. Knowledge, Technology & Policy (Springer) 14 (2): 88-112. doi:10.1007/PL00022278.
  22. ↑ “Support for Windows XP”. Microsoft. 2026年8月19日閲覧。
  23. ↑ “Balancing on the high wire of Microsoft's success”. Computerworld. 1987年11月2日. 2026年8月19日閲覧.
  24. ↑ “Favoritism and the small firms”. Computerworld. 1986年7月7日. 2026年8月19日閲覧.
  25. ↑ “The great software debate”. Computerworld. 1987年11月2日. 2026年8月19日閲覧.
  26. ↑ “LSB Introduction”. Linux Foundation. 2026年8月19日閲覧。
  27. ↑ “Update on Standards”. USENIX. 2026年8月19日閲覧。
  28. ↑ Kevin Bierhoff (2009). “API Protocol Compliance in Object-Oriented Software”. CMU Institute for Software Research 2026年8月19日閲覧。.
  29. ↑ “Get smart with proxies and RMI”. JavaWorld. 2026年8月19日閲覧。
  30. ↑ Henning, Michi (1999) (英語). Advanced CORBA Programming with C++. Addison-Wesley. ISBN 978-0-201-37927-3
  31. ↑ Djamal Benslimane; Schahram Dustdar; Amit Sheth (2008). “Services Mashups: The New Generation of Web Applications”. IEEE Internet Computing (IEEE) 12 (5): 13-15. doi:10.1109/MIC.2008.110.
  32. ↑ “So What Is an Enterprise Mashup, Anyway?”. PC World. 2026年8月19日閲覧。
  33. ↑ “The Evolution of the Social Media API”. Mashable. 2026年8月19日閲覧。
  34. ↑ “GET trends/place”. Twitter. 2026年8月19日閲覧。
  35. ↑ “F2PY.org”. F2PY.org. 2011年12月18日閲覧。
  36. ↑ D.L. Parnas (1972). “On the Criteria To Be Used in Decomposing Systems into Modules”. Communications of the ACM (ACM) 15 (12): 1053-1058. doi:10.1145/361598.361623.
  37. ↑ David Garlan; Mary Shaw (1994). “An Introduction to Software Architecture”. Advances in Software Engineering and Knowledge Engineering 1 2026年8月19日閲覧。.
  38. 1 2 3 “Red Hat Enterprise Linux 8: アプリケーションの互換性ガイド”. Red Hat Customer Portal (2024年3月25日). 2026年3月19日閲覧。
  39. 1 2 “Microsoft Graph のバージョン管理、サポートと重大な変更の方針”. Microsoft Learn (2024年11月7日). 2026年3月19日閲覧。
  40. 1 2 “API のバージョニング”. Google Cloud Documentation (2026年3月16日). 2026年3月19日閲覧。
  41. 1 2 “OpenAPI Specification v3.2.0” (英語). OpenAPI Initiative (2025年9月19日). 2026年3月19日閲覧。
  42. ↑ “API仕様（OpenAPI Specification）”. デジタル庁 開発者サイト (2025年10月23日). 2026年3月19日閲覧。
  43. ↑ Uri Dekel; James D. Herbsleb (2009). “Improving API Documentation Usability with Knowledge Pushing”. Institute for Software Research, School of Computer Science.
  44. ↑ Measuring API documentation on the web. Proceedings of the 2nd International Workshop on Web 2.0 for Software Engineering (英語). 2011. 2026年8月19日閲覧.
  45. ↑ Waleed Maalej; Martin P. Robillard (2012). “Patterns of Knowledge in API Reference Documentation”. IEEE Transactions on Software Engineering (IEEE) 39 (9): 1264-1282. doi:10.1109/TSE.2013.12.
  46. ↑ Martin Monperrus; Michael Eichberg; Elif Tekes; Mira Mezini (2011). “What should developers be aware of? An empirical study on the directives of API documentation”. Empirical Software Engineering 17 (6): 703-737. doi:10.1007/s10664-011-9186-4.
  47. 1 2 An Empirical Study on Evolution of API Documentation. International Conference on Fundamental Approaches to Software Engineering (英語). 2011. 2026年8月19日閲覧.
  48. ↑ “Annotations”. Sun Microsystems. 2026年8月19日閲覧。
  49. ↑ Mining subclassing directives to improve framework reuse. 2010 7th IEEE Working Conference on Mining Software Repositories (MSR 2010) (英語). 2010. 2026年8月19日閲覧.
  50. ↑ “CWE - CWE-798: Use of Hard-coded Credentials (4.20)”. cwe.mitre.org. 2026年8月19日閲覧。
  51. ↑ “シークレット スキャンからのアラートの解決 - GitHubドキュメント”. GitHub Docs. 2026年8月19日閲覧。
  52. ↑ “クラウドパスワード管理、認証情報ストレージ – AWS Secrets Manager – AWS”. Amazon Web Services, Inc.. 2026年8月19日閲覧。
  53. 1 2 “OWASP Top 10 API Security Risks – 2023 - OWASP API Security Top 10”. owasp.org. 2026年8月19日閲覧。
  54. ↑ “API キーを管理 | Authentication”. Google Cloud Documentation. 2026年8月19日閲覧。
  55. ↑ “API Gateway での REST API の使用量プランと API キー - Amazon API Gateway”. docs.aws.amazon.com. 2026年8月19日閲覧。
  56. ↑ “Business Ecosystem: Creating an Economic Moat”. BoostCompanies. 2026年8月19日閲覧。
  57. ↑ “Private, Partner or Public: Which API Strategy Is Best for Business?”. ProgrammableWeb. 2026年8月19日閲覧。
  58. ↑ “Car Service APIs Are Everywhere, But What's In It For Partner Apps?”. AdExchanger. 2026年8月19日閲覧。
  59. ↑ “Cloudflare API v4 Documentation”. Cloudflare. 2026年8月19日閲覧。
  60. ↑ “Car Service APIs Are Everywhere, But What's In It For Partner Apps”. Smashing Magazine. 2026年8月19日閲覧。
  61. ↑ “google/guava: Google Core Libraries for Java”. GitHub. 2026年8月19日閲覧。
  62. ↑ “How and When to Deprecate APIs”. Oracle. 2026年8月19日閲覧。
  63. ↑ Empirical evidence of large-scale diversity in API usage of object-oriented software. 2013 IEEE 13th International Working Conference on Source Code Analysis and Manipulation (SCAM) (英語). 2013. 2026年8月19日閲覧.
  64. ↑ “Akamai: Cybercriminals are attacking APIs at financial services firms”. Venture Beat. 2026年8月19日閲覧。
  65. ↑ “Oracle and the End of Programming As We Know It”. DrDobbs (2012年5月1日). 2012年5月2日時点のオリジナルよりアーカイブ。2012年5月9日閲覧。
  66. ↑ “APIs Can't be Copyrighted Says Judge in Oracle Case”. TGDaily. 2026年8月19日閲覧。
  67. ↑ “Oracle America, Inc. vs. Google Inc.”. Wired. 2026年8月19日閲覧。
  68. ↑ “Oracle Am., Inc. v. Google Inc., No. 13-1021, Fed. Cir. 2014”. Justia Law. 2026年8月19日閲覧。
  69. ↑ “Court sides with Oracle over Android in Java patent appeal”. CNET. 2014年5月9日. 2026年8月19日閲覧.
  70. ↑ “Google beats Oracle – Android makes "fair use" of Java APIs”. Ars Technica. 2026年8月19日閲覧。
  71. ↑ “Oracle Wins Revival of Billion-Dollar Case Against Google”. Bloomberg Businessweek. 2026年8月19日閲覧。
  72. ↑ “Google asks Supreme Court to overrule disastrous ruling on API copyrights”. Ars Technica. 2026年8月19日閲覧。
  73. ↑ “Google LLC v. Oracle America, Inc.”. LII / Legal Information Institute. 2026年8月19日閲覧。
  74. ↑ “［速報］10年にわたる著作権訴訟でGoogleがオラクルに勝訴、米連邦最高裁判所で判決。Java SEのコードのコピーはフェアユースの範囲”. Publickey (2021年4月6日). 2021年4月7日閲覧。
  75. ↑ 松下正. “知的財産権（特許・商標・著作権）の基礎講座”. 知的財産権（特許・商標・著作権）の基礎講座. 2015年7月1日閲覧。
  76. ↑ “Programming Interface (System Interface Guide)”. docs.oracle.com. 2024年12月13日閲覧。
  77. ↑ “Introduction to system programming commands” (英語). www.ibm.com. 2024年12月13日閲覧。
  78. ↑ “Job scheduler System Programming Interfaces (SPI)” (英語). www.ibm.com. 2024年12月13日閲覧。
  79. ↑ UEFI firmware requirements | Microsoft Docs
  80. 1 2 U.S. Department of Commerce, National Bureau of Standards (1981年4月). Database architectures – a feasibility workshop (Report). 2026年8月19日閲覧.
  81. 1 2 3 4 “A Brief, Opinionated History of the API”. InfoQ. 2026年8月19日閲覧。
  82. 1 2 Data structures and techniques for remote computer graphics. AFIPS 1968 Fall Joint Computer Conference (英語). 1968. 2026年8月19日閲覧.
  83. ↑ “application program interface”. Oxford English Dictionary. 2026年8月19日閲覧。
  84. ↑ Date, C. J. (2019) (英語). E. F. Codd and Relational Theory: A Detailed Review and Analysis of Codd's Major Database Writings. Lulu.com. ISBN 978-1-68470-527-6
  85. ↑ The relational and network approaches: Comparison of the application programming interfaces. SIGMOD Workshop 1974 (英語). 1975. 2026年8月19日閲覧.
  86. ↑ Malamud, Carl (1990) (英語). Analyzing Novell Networks. Van Nostrand Reinhold. ISBN 978-0-442-00364-7
  87. 1 2 Jin, Brenda (2018) (英語). Designing Web APIs. O'Reilly Media. ISBN 978-1-4920-2687-7
  88. ↑ “Architectural Styles and the Design of Network-based Software Architectures”. UC Irvine. 2026年8月19日閲覧。
  89. ↑ Fefie Dotsika (2010). “Semantic APIs: Scaling up towards the Semantic Web”. International Journal of Information Management (Elsevier) 30 (4): 335-342. doi:10.1016/j.ijinfomgt.2009.12.003.
  90. ↑ “AIの「タダ乗り」許さず--Wikipedia、AI企業に無断利用の停止と支払いを要求”. CNET Japan (2025年11月11日). 2025年11月11日閲覧。
  91. ↑ “Wikipedia運営元、AI企業にAPIを介したデータ使用料支払いを要求”. ITmedia NEWS. 2025年11月11日閲覧。
  92. ↑ “WikipediaがAI開発者に有料APIの利用を促す - GIGAZINE”. gigazine.net (2025年11月11日). 2025年11月12日閲覧。

参考文献

関連項目

外部リンク