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

ウィキペディア

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

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2024/04/26 03:40 UTC 版)

概要

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

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

APIと非API

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

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

ライブラリー形式の非API

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

ライブラリとAPI

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

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

APIはサービスを利用するうえで必須になるが、APIを直接使用することは外部サービスに対する依存性を高め移植性を妨げる。例えば前述のWriteFileを使うプログラムは基本的にWindows用にしかコンパイルできないが、fwriteを使うプログラムはフリースタンディング環境以外ならどの環境でもコンパイルできる。このため移植性を考えるのであればAPIの直接使用は避け、APIを抽象化したライブラリを使用することが望ましい。 さらに、後述するように移植性を意識する言語ではライブラリとAPIを厳密に区別している場合が多い。特に後述のSmalltalkはクロスプラットフォームが一つの長所となっているためAPIの直接使用を避けることは重要となる。

C++の規格書では、API関数とライブラリ関数は一貫して区別されており、API関数は標準のライブラリ関数から呼び出されるもの、あるいは標準ライブラリの関数が同等の機能を模倣する対象として書かれている。またCの規格書においてはAPIという言葉は無く、相当する関数がライブラリ関数以外の関数として書かれている。1980年代から存在するSmalltalkでもAPIとライブラリは区別されており、例えばSmalltalk環境の一種であるPharoはAPIと対応しているパッケージをライブラリとは別にAPIとして区分している [1]。

なお、標準ライブラリはOSやファームウェアなどアプリケーション以外からも使われる。

詳細

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

APIはソフトウェアライブラリと対応しているのが一般的である。 APIは「期待される挙動」を規定し説明するが、ライブラリはその規則群の「実際の実装」である。 1つのAPIが複数の実装を持つこともあるし、実装のない抽象的APIもありうる。

広義のAPIはソフトウェアフレームワークと対応する場合もある。フレームワークはいくつかのライブラリを備え、いくつかのAPIを実装することもあるが、通常のAPIとは使い方が異なり、「フレームワークに組み込まれた」挙動への「アクセス」としてフレームワーク自身に新たなクラスをプラグインすることでその内容を拡張するという手段をとる。さらに言えば、呼び出し側はプログラムの動作を制御できず、制御の反転や他の類似の機構によってフレームワーク側が流れを制御する。

APIとプロトコル

APIはプロトコルの実装となっていることもある。

プロトコルは、共通の転送手段に基づいた要求と応答の標準的交換方法を定義している。一方プロトコルを実装していないAPIは、ライブラリとして実装され、直接使われるのが一般的である。したがってAPIには「転送手段」が関与することはなく（遠隔のマシンとの物理的情報転送を行わない）、「関数呼び出し」によって単純に情報交換し、データは特定の言語で表現された形式で交換される。

APIがプロトコルの実装である場合、下層にある通信プロトコルを使ってリモート呼び出しを行うためのプロキシ的手段となっている。その場合のAPIの役目は、プロトコルの詳細を隠蔽することである。例えばJava RMIは、JRMPプロトコルまたはRMI-IIOPとしてのIIOPを実装している。

プロトコルは一般に異なるテクノロジー（特定OS内の特定プログラミング言語に基づくシステム）間をつなぎ、それらの間での情報交換を可能にしている。一方APIは特定のテクノロジーに固有であり、何らかの変換手段を用いない限り、ある言語用のAPIを別の言語では使用できない。

オブジェクトAPIとプロトコル

オブジェクトAPIは具体的なオブジェクト交換フォーマットを規定し、オブジェクト交換プロトコルはメッセージ内の同種の情報をリモートシステムに転送する方法を定義する。

2つの異なるプラットフォーム間で、両者にあるオブジェクトを使ってプロトコル経由でメッセージを交換する場合、あるプログラミング言語内のオブジェクトは相手の異なる言語でのオブジェクトに変換される。例えばJavaで書かれたプログラムがC#で書かれたサービスをSOAPやIIOP経由で呼び出す場合、どちらのプログラムもリモート呼び出し用API（API自体はローカルに存在する）を使って情報交換し、ローカルなメモリ内でオブジェクトの変換を行う。

一方、同一マシン上でAPI経由のオブジェクト交換を行う場合、メモリ内で効率的に（オブジェクトまたはオブジェクトへの参照の）交換が行われる。例えば、1つのプロセスに割り当てられたメモリということもあるし、共有メモリを使って複数プロセス間で行うこともあるし、タプルスペースのような共有技法を使うこともある。