この記事には独自研究が含まれているおそれがあります。問題箇所を検証し出典を追加して、記事の改善にご協力ください。議論はノートを参照してください。（2019年10月）
.mw-parser-output .hatnote{margin:0.5em 0;padding:3px 2em;background-color:transparent;border-bottom:1px solid #a2a9b1;font-size:90%}

ウィキペディアなど、MediaWikiに対して使えるAPIについては、MediaWikiの解説ページをご覧ください。

アプリケーションプログラミングインタフェース（API、英: application programming interface）[注釈 1]とは、広義ではソフトウェアコンポーネント同士が互いに情報をやりとりするのに使用するインタフェースの仕様である。

APIには、サブルーチン、データ構造、オブジェクトクラス、変数などの仕様が含まれる。APIには様々な形態があり、POSIXのような国際標準規格、マイクロソフトのWindows APIのようなベンダーによる文書、プログラミング言語の標準ライブラリ（例えば、C++のStandard Template LibraryやJava API（英語版）など）がある。

商業的に使われる狭義では、各種システムやサービス（ハードウェア、OS、ミドルウェアおよびWebサービス等）を利用するアプリケーションソフトウェア (Application) を開発・プログラミング (Programming) するためのインタフェース (Interface) である[1][2][3][4][5]。こちらの意味では、システムやサービスから直接提供されないもの、例えば言語の標準ライブラリは含まない。

APIはアプリケーションバイナリインタフェース (ABI) とは異なる。APIはソースコードベースだが、ABIはバイナリインタフェースである。例えば、POSIXはAPIだが、Linux Standard Base (LSB) はABIである[6]（LSBはいろいろな規定の集合なので、正確には「LSBには、ABIにまで踏み込んでいる部分もある」）。
概要

広義のAPIでは単なるライブラリのインタフェースを含むかどうかにばらつきがあるなど定義が曖昧であるため、ここでは狭義のAPIについて説明する。

前述のとおりAPIは各種システム／サービスがそのシステム／サービスを利用するアプリケーションに対して公開するインタフェースである。APIの重要な役割は、システム／サービス提供者が公式に仕様（外部仕様）を定義し、管理している各種機能を利用するための操作方法（インタフェース）を提供することである。APIは多くの場合、アプリケーションを構築する言語と同じ言語のライブラリ、あるいは通信プロトコル形式[注釈 2]として提供され、システム／サービス開発者によって提供・管理される。
APIと非API

アプリケーションがシステム／サービスを利用するには、APIを無視してシステム／サービスの現在の実装および内部仕様に依存した方法がある。人と同じ操作をアプリケーションにさせたり、たまたま設定が書き込まれていたファイルをアプリケーションで読み取るなどである。この手法を非API[7]と言い英語圏ではnon-API[8][9]あるいはnon API[10]と呼ぶ。システム／サービス提供者はアプリケーションがAPI以外の仕様や実装に依存していることは関知せず、API以外の仕様や実装が永続的に維持されることも保証しない。このため非APIを使ったアプリケーションは、バグ修正などで少しでもシステム／サービスの内部仕様に変更があれば、たちまち動かなくなってしまう。この点、APIを使用する場合は、システム／サービスが更新されてもAPIが提供者によって後方互換性を維持してくれるため、アプリケーション側の変更は必要ない(ただし頻繁ではないが提供者により互換性がなくなる場合もある)。アプリケーションがシステム／サービスを操作するにあたり、APIにだけ依存することでこのような互換性の問題を避けることができる。

ただし、APIを使う場合、APIの提供者から使用回数などに制限を掛けられる場合があり[8]それをらの制限を回避するためやAPIを提供していないシステム／サービスを使うために非APIを使う技術が重要になる場合もある。
ライブラリー形式の非API

Microsoft Windows、macOS、iOS、AndroidなどのOSには、API以外に、俗に「隠しAPI」や「プライベートAPI」「非公開API」などと呼ばれるライブラリー形式の非APIが存在する。これらの非APIは特定の共通処理をアプリケーション側ではなくシステム内部でのみ再利用することを想定して実装されており[7]、例えばWindowsでは一部の非API関数がシステムDLLにエクスポートされていることから、LoadLibrary 関数を使用してAPI関数エントリポイントを動的ロードすることで呼び出すことができる。Javaや.NET Frameworkの場合は、カプセル化を破壊することになるが、隠蔽されたメソッドであってもリフレクションを使用して呼び出すことができる。しかし、これらはシステム／サービス提供者が公式に提供している機能ではなくAPIではない。このためこれらの隠し機能を使ったアプリケーションの動作は保証されないし、互換性も将来に渡って保証されることはない。例えばWindows APIにおいて、timeBeginPeriod(), timeEndPeriod() はアプリケーション開発者向けに正式公開・ドキュメント化されているAPI関数だが、これらは内部でNtSetTimerResolution()を呼び出している[11]。NtSetTimerResolution()は、Windows NT系のシステムDLLのひとつ、ntdll.dllにエクスポートされているが、アプリケーション開発者向けのドキュメントには記載されていない非API関数であり[12]、この非API関数をアプリケーションで直接使用した場合の結果は保証されない。EclipseではPlugin開発にて非APIを使った場合エラーを出す設定がある[13]。Appleが提供するApp StoreではAppleが作成した非APIを使ったアプリケーションは掲載を拒否される[14]。
ライブラリとAPI

この節には独自研究が含まれているおそれがあります。問題箇所を検証し出典を追加して、記事の改善にご協力ください。議論はノートを参照してください。（2019年10月）

この節の正確性に疑問が呈されています。問題箇所に信頼できる情報源を示して、記事の改善にご協力ください。議論はノートを参照してください。（2019年10月）

APIは関数、プロシージャ、変数やデータ構造といったライブラリによって実装されることが多いが、狭義のAPIではライブラリとAPIは同一ではない。ライブラリ形式ではなくプロトコル形式で提供される場合もあるという理由もあるが、ライブラリ形式である場合も同一視せず区別する必要があるという理由がある。

例えばAPIが関数であればサービスにより提供される関数はAPI関数と呼ぶが、API関数を利用して構築された関数はAPIではないためライブラリ関数と呼ぶ。ライブラリ関数は直接サービスと関係ないか、APIを使って構築されておりサービスを利用する上で必須ではない。逆にAPI関数の存在はサービスを利用する上で必須である。例えばC言語の標準ライブラリ関数であるfwriteは、Windows上ではAPI関数である WriteFile を使って実装されている。WriteFileはOSの機能に直接アクセスできることからfwriteよりも高機能であり、別OSへの移植性を考えなければfwriteの代わりにWriteFileを直接利用してアプリケーションを記述することもできる。