アプリケーションプログラミングインタフェース
アプリケーションプログラミングインタフェース（API、英: Application Programming Interface）とは、広義の意味ではソフトウェアコンポーネントが互いにやりとりするのに使用するインタフェースの仕様である。
APIには、サブルーチン、データ構造、オブジェクトクラス、変数などの仕様が含まれる。APIには様々な形態があり、POSIXのような国際規格、マイクロソフトのWindows APIのようなベンダーによる文書、プログラミング言語のライブラリ（例えば、C++のStandard Template LibraryやJava APIなど）がある。
商業的に使われる狭義の意味ではOSやミドルウェアやWebサービス等サービスを利用するアプリケーション(Application)を作成する(Programming)ためのインターフェース(Interface)である。[1][2][3][4][5]こちらの意味ではサービスから提供されないStandard Template Libraryなど言語の標準ライブラリーは含まない。
APIはApplication Binary Interface (ABI) とは異なる。APIはソースコードベースだが、ABIはバイナリインタフェースである。例えば、POSIXはAPIだが、Linux Standard Base (LSB) はABIである[6]（LSBはいろいろな規定の集合なので、正確には「LSBには、ABIにまで踏み込んでいる部分もある」）。
目次
1 概要
1.1 ライブラリーとAPI
2 詳細
2.1 ライブラリとフレームワーク
2.2 APIとプロトコル
2.2.1 オブジェクトAPIとプロトコル
3 ウェブAPI
3.1 ウェブによるコンテンツ共有
4 実装
5 公開の方針
6 リバースエンジニアリングと著作権
7 類似する概念
8 APIの例
9 言語束縛とインタフェースジェネレータ
10 脚注
11 関連項目
12 外部リンク
概要
広義のAPIでは単なるライブラリーのインターフェースを含むかどうかにばらつきがあるなど定義が曖昧であるため、ここでは狭義のAPIについて説明する。
前述のとおりAPIはサービスがサービスを利用するアプリケーションに提供するためのインターフェースである。APIの重要な役割はサービス提供者が公式に仕様を定義し管理している操作方法(インターフェース)を提供することである。APIは多くの場合アプリケーションを構築する言語と同じ言語のライブラリーとして(HTTPやXMLなどを組み合わせたプロトコル形式の場合もある)提供され、サービス開発者によって提供・管理される。
アプリケーションがサービスを利用するにはAPIを無視してサービスの現在の実装に依存した方法で利用することもできるが、サービス提供者はアプリケーションがAPI以外の仕様に依存していることは認知しておらずAPI以外の仕様が永続的に維持されることも保証しない。バグ修正などで少しでもサービスに変更があればAPIを利用しないアプリケーションはたちまち動かなくなってしまう。アプリケーションがサービスを操作するにあたりAPIにだけ依存することでこのような永続性の問題を防ぐことができるのである。
なお、APIを備えたサービスとして代表的なOSにWindowsやOSXやiOSがあるが、これらには俗に隠しAPIやプライベートAPIなどと呼ばれるものが存在した。これらはサービス提供者が公式に提供している機能ではなくAPIではない。このためこれらの機能を使ったアプリケーションの将来は保証されることはない。
ライブラリーとAPI
APIは関数、プロシージャ、変数やデータ構造といったライブラリーによって実装されることが多いが、狭義のAPIではライブラリーとAPIは同一ではない。
ライブラリー形式ではなくプロトコル形式で提供される場合もあるという理由もあるが、ライブラリー形式である場合も同一視せず区別する必要があるという理由がある。
例えばAPIが関数であればサービスにより提供される関数はAPI関数と呼ぶが、API関数を利用して構築された関数はAPIではないためライブラリー関数と呼ぶ。
ライブラリー関数は直接サービスと関係ないか、APIを使って構築されておりサービスを利用する上で必須ではない。逆にAPI関数の存在はサービスを利用する上で必須である。例えばCのライブラリー関数であるfwrite[7]はWindows上であればAPI関数であるWriteFile[8]を使って実装されておりOS間の移植性を考えなければfwriteでなくWriteFileで代替できる。
APIはサービスを利用するうえで必須になるが、APIを直接使用することは外部サービスに対する依存性を高め移植性を妨げる。例えばWriteFileを使うプログラムは基本的にWindows用にしかコンパイルできないがfwriteを使うプログラムはフリースタンディング環境以外ならどの環境でもコンパイルできる。このため移植性を考えるのであればAPIの直接使用は避けAPIを抽象化したライブラリーを使用することが望ましい。
さらに、後述するように移植性を意識する言語ではライブラリーとAPIを厳密に区別している場合が多い。特に後述のSmalltalkはクロスプラットフォームが一つの長所となっているためAPIの直接使用を避けることは重要となる。
C++の規格書では、API関数とライブラリー関数は一貫して区別されており、API関数は標準のライブラリー関数から呼び出されるもの、あるいは標準ライブラリーの関数が同等の機能を模倣する対象として書かれている。[9]またCの規格書においてはAPIという言葉は無く相当する関数がライブラリー関数以外の関数として書かれている。[10]1980年代から存在するSmalltalkでもAPIとライブラリーは区別されており例えばSmalltalk環境の一種であるPharoはAPIと対応しているパッケージをライブラリーとは別にAPIとして区分している。[1]
なお、標準ライブラリーはOSやファームウェアなどアプリケーション以外からも使われる。
詳細
ライブラリとフレームワーク
APIはソフトウェアライブラリと対応しているのが一般的である。
APIは「期待される挙動」を規定し説明するが、ライブラリはその規則群の「実際の実装」である。
1つのAPIが複数の実装を持つこともあるし、実装のない抽象的APIもありうる。
広義のAPIはソフトウェアフレームワークと対応する場合もある。フレームワークはいくつかのライブラリを備え、いくつかのAPIを実装することもあるが、通常のAPIとは使い方が異なり、「フレームワークに組み込まれた」挙動への「アクセス」としてフレームワーク自身に新たなクラスをプラグインすることでその内容を拡張するという手段をとる。さらに言えば、呼び出し側はプログラムの動作を制御できず、制御の反転や他の類似の機構によってフレームワーク側が流れを制御する[11]。
APIとプロトコル
APIはプロトコルの実装となっていることもある。
プロトコルは、共通の転送手段に基づいた要求と応答の標準的交換方法を定義している。一方プロトコルを実装していないAPIは、ライブラリとして実装され、直接使われるのが一般的である。したがってAPIには「転送手段」が関与することはなく（遠隔のマシンとの物理的情報転送を行わない）、「関数呼び出し」によって単純に情報交換し、データは特定の言語で表現された形式で交換される[12]。
APIがプロトコルの実装である場合、下層にある通信プロトコルを使ってリモート呼び出しを行うためのプロキシ的手段となっている。その場合のAPIの役目は、プロトコルの詳細を隠蔽することである。例えばJava RMIは、JRMPプロトコルまたはRMI-IIOPとしてのIIOPを実装している。
プロトコルは一般に異なるテクノロジー（特定OS内の特定プログラミング言語に基づくシステム）間をつなぎ、それらの間での情報交換を可能にしている。一方APIは特定のテクノロジーに固有であり、何らかの変換手段を用いない限り、ある言語用のAPIを別の言語では使用できない。
オブジェクトAPIとプロトコル
オブジェクトAPIは具体的なオブジェクト交換フォーマットを規定し、オブジェクト交換プロトコルはメッセージ内の同種の情報をリモートシステムに転送する方法を定義する。
2つの異なるプラットフォーム間で、両者にあるオブジェクトを使ってプロトコル経由でメッセージを交換する場合、あるプログラミング言語内のオブジェクトは相手の異なる言語でのオブジェクトに変換される。例えばJavaで書かれたプログラムがC#で書かれたサービスをSOAPやIIOP経由で呼び出す場合、どちらのプログラムもリモート呼び出し用API（API自体はローカルに存在する）を使って情報交換し、ローカルなメモリ内でオブジェクトの変換を行う。
一方、同一マシン上でAPI経由のオブジェクト交換を行う場合、メモリ内で効率的に（オブジェクトまたはオブジェクトへの参照の）交換が行われる。例えば、1つのプロセスに割り当てられたメモリということもあるし、共有メモリを使って複数プロセス間で行うこともあるし、タプルスペースのような共有技法を使うこともある。
ウェブAPI
ウェブ開発においては、APIは一般にHTTP要求メッセージ群とXMLまたはJSON形式などの応答メッセージの構造定義で構成される。「ウェブAPI」はWebサービスと事実上同義だが、Web 2.0と呼ばれる最近の傾向では、SOAPベースからREST風の直接的通信へと変化している[13]。ウェブAPIはマッシュアップと呼ばれる技法で複数のサービスを組み合わせて新たなアプリケーションとすることを可能にする[14]。
ウェブによるコンテンツ共有
APIを公表する慣習により、ウェブコミュニティにはコミュニティ間やアプリケーション間でコンテンツとデータを共有するオープンアーキテクチャが発展していった。そのため、ある場所で作成されたコンテンツはウェブ上の様々な場所で盛んにポストされ更新される。
- 写真はFlickrやPhotobucketといったサイトからFacebookやMyspaceといったソーシャルネットワークサイトに共有される。
- コンテンツは埋め込むこともできる。例えば、SlideShareにあるプレゼン資料をLinkedInのプロファイル情報に埋め込むことができる。
TwitterのつぶやきをFacebookの投稿にも同時に反映させるAPIもある。- 動画コンテンツも別のホスト上のサイトに埋め込むことができる。
- ウェブコミュニティにおけるユーザー情報を外部アプリケーションと共有させることができ、アプリケーションの更新をウェブ側から働きかけるなどの機能もオープンなAPIで実現されている。好例としてFacebookプラットフォームやOpenSocialプラットフォームがある。
実装
POSIX標準は、様々な一般的コンピューティング機能を各種システム上で実装できるよう考慮したAPIを定義している。例えば、macOSやBSD系システムで実装されている。ただし、POSIX準拠のプログラムを別のPOSIX準拠のプラットフォームで実行するには、再コンパイルが必要である。
一方、互換APIの場合、そのAPIを実装したシステムならどこでも同じオブジェクトファイルがそのまま実行可能である。これはソフトウェア業者にもユーザーにも有益であり、業者は互換APIが実装されていれば新システムが登場しても製品を修正せずに済むし、ユーザーも古いソフトウェアを新システムにインストールできる。ただし、それには一般に各種ライブラリが必要なAPI群を実装している必要がある。
マイクロソフトはAPIの後方互換性の維持を心がけており、特にWindows API (Win32) ライブラリは古いアプリケーションが新しいWindows上でも動作できるよう互換モードを備えている[15]。
Unix系OSでは、相互に関連はあるが非互換なOS群が同一ハードウェア上で動作している。ソフトウェア業者が同一バイナリで各種OSに対応できるようAPIとABIを共通化する試みがなされてきたが、いずれも失敗に終わっている。そのような試みとしてLinuxではLinux Standard Baseがある。BSD系OSも各種あるが、互換性のレベルは様々である。
公開の方針
APIの公開に関しては2つの一般的な方針がある。
- 自社のAPIを厳重に秘匿する。
- 例えばソニーはライセンスをもった開発者にしかプレイステーションの公開APIを利用できないようにしている。なぜならプレイステーションのゲームを開発できる人の数を制限したほうが、より多くの利益をあげられるからである。これはAPIの実装を売ることで利益を上げるわけではない会社の典型的な例である。（ソニーの場合は、ゲーム開発時のAPIのライセンス料によって利益を上げようとしたがうまくいかず、プレイステーション用コンソールの販売を中止している。）
- 自社のAPIを広く普及させる。
- 例えばマイクロソフトは計画的にAPIに関する情報を公開しているので、誰でも簡単にWindowsプラットフォーム用のソフトウェアを作成することができる。これはAPIの実装を販売して利益をあげる会社の例である。OSなどのAPIは、いくつかのコードに分割され、ライブラリとして実装されており、OSと一緒に配布される。OSと一緒に配布されるWindowsのAPIは誰でも使うことができる。また直接アプリケーションの中に統合される必要があるAPIもある。
この2つの方針の中間もある。
リバースエンジニアリングと著作権
互換性のためのAPIを作成するためにそのAPIの実装を解析することは一般的に合法である。この手法は相互運用性のためのリバースエンジニアリングと呼ばれる。しかしAPIそのものとは異なり、APIの実装には著作権が存在するため、リバースエンジニアリングする前には著作権侵害の問題が生じないよう、十分注意する必要がある。また、使おうとしているAPIに、特許保持者の許可がなければ使えない特許技術が許可なく含まれていたら、それは特許権侵害になりうる。（ただし、これはリバースエンジニアリングに限られた話ではなく、APIを利用するプログラムにも全般的に言えることである。）
2010年、米オラクルはGoogleがJavaの新たな実装をAndroidの一部として配布したとして、Googleを訴えた[16]。GoogleはJava APIを複製する許可をとっていなかったが、類似の許可はOpenJDKプロジェクトに与えられていた。これに対して、地方裁判所はAPIは著作権法の対象外であるとする判断を下したものの、控訴裁では保護対象であるとされ、最終的に2015年、最高裁によりアメリカ合衆国内ではAPIにも著作権があるとの判断が確定した[17][18][19]。ただし著作権があってもフェアユースの下に利用可能かについては、2015年現在継続して審理されている。
日本においては、著作権法第10条第3項において、プログラムのインタフェースやプロトコルが著作物とみなされないことが明確に示されている[20]。
類似する概念
DDI - デバイスドライバーを開発するためのソフトウェアインターフェース
ファームウェアインターフェース - ファームウェアを開発するためのソフトウェアインターフェース
ASPI - SCSI 装置を制御するためのソフトウェアインターフェース
特にDDIやファームウェアインターフェースを使う場合はソフトウェアがアプリケーションと異なる環境で動作しAPIに依存するライブラリを使用できない場合があるため、開発者は自分が何を使っているか意識する必要がある。
APIの例
CarbonとCocoa - macOS
- CORBA
Document Object Model (DOM) - HTML文書やXML文書をアプリケーションから利用するためのAPI
DirectX - Microsoft Windows
- EHLLAPI
iconv - 文字コード間の相互変換用API（POSIXの一部）- I/OKit - Darwin
- Java API
ODBC - Microsoft Windows
OpenAL - クロスプラットフォームのオーディオAPI
OpenCL - CPUやGPUを汎用処理に使用するためのクロスプラットフォームのAPI
OpenGL - クロスプラットフォームのグラフィックスAPI
OpenMP - クロスプラットフォームの共有メモリ型マルチプロセッシング用API。C、C++、Fortranで利用可能。- POSIX
- QuickTime
- Single UNIX Specification
Simple DirectMedia Layer (SDL)- Toolbox - Mac OS
Video for Windows - Microsoft Windows
Windows API - Microsoft Windows
- XPCOM
EXtelligence API- EDIを組み込めるAPI
言語束縛とインタフェースジェネレータ
複数の高水準言語での使用を意図したAPIは、文法的・意味的に各言語に適したインタフェースをAPIに自動的にマッピングする機能を提供している。これを言語束縛と呼び、それ自体もAPIである。その目的は、そのAPIに要求される機能のほとんどをカプセル化するため、各言語に薄い層を設けることである。
以下に挙げたものは、コンパイル時に言語とAPIの束縛を行うインタフェースジェネレータである。
SWIG - オープンソースの多言語間のインタフェースジェネレータ（通常はC/C++からスクリプト言語へのインタフェースを生成）- F2PY:[21] - FortranからPythonへのインタフェースジェネレータ
脚注
^ https://www.ibm.com/support/knowledgecenter/ja/SS4SVW_2.0.0/com.ibm.zosconnect.doc/backmatter/glossary.html#glossary__api
^ https://developer.mozilla.org/ja/docs/Glossary/API
^ http://www.ocn.ne.jp/support/words/abc/API.html
^ https://www.synergy-marketing.co.jp/glossary/api/
^ Smalltalk環境の提供元Cincomによる見積サービスの説明 APIの解説がある。
^ Stoughton, Nick (2005年4月). “Update on Standards (PDF)”. USENIX. 2009年6月4日閲覧。
^ https://www.ibm.com/support/knowledgecenter/ja/SSLTBW_2.2.0/com.ibm.zos.v2r2.cbcpx01/write.htm
^ https://msdn.microsoft.com/ja-jp/library/cc429856.aspx
^ C++14の規格書の最終草案
^ C14の規格書の最終草案
^ Fowler, Martin. “Inversion Of Control”. 2012年10月18日閲覧。
^ “API vs Protocol”. 2012年10月18日閲覧。
^ Benslimane, Djamal; Schahram Dustdar, and Amit Sheth (2008年). “Services Mashups: The New Generation of Web Applications”. IEEE Internet Computing, vol. 12, no. 5. Institute of Electrical and Electronics Engineers. pp. 13–15. 2012年10月18日閲覧。
^ Niccolai, James (2008-04-23), “So What Is an Enterprise Mashup, Anyway?”, PC World, http://www.pcworld.com/businesscenter/article/145039/so_what_is_an_enterprise_mashup_anyway.html
^ Microsoft. “Getting older programs to run on Windows XP”. Microsoft. 2012年10月18日閲覧。
^ “Oracle and the End of Programming As We Know It”. DrDobbs (2012年5月1日). 2012年5月9日閲覧。
^ Josh Lowensohn (2012年5月23日). “Jury clears Google of infringing on Oracle's patents”. ZDNet. 2012年5月25日閲覧。
^ Joe Mullin (2012年5月31日). “Google wins crucial API ruling, Oracle’s case decimated”. Ars Technica. 2012年6月1日閲覧。
^ “米最高裁がGoogleの訴えを却下、OracleとのJava著作権訴訟で”. ITPro (2015年6月30日). 2015年7月1日閲覧。
^ 松下正. “知的財産権（特許・商標・著作権）の基礎講座”. 知的財産権（特許・商標・著作権）の基礎講座. 2015年7月1日閲覧。
^ “F2PY.org”. F2PY.org. 2011年12月18日閲覧。
関連項目
- システムコール
- 呼出規約
- Foreign function interface
- 名前修飾
- プラグイン
- ソフトウェア開発キット
外部リンク
- What is an API? Your Guide to the Internet (R)evolution
- How to design a good API and why it matters
- How to Design APIs for Cryptographic Protocols
| ||||||||||||||||||||||||
コンピュータ - 
カテゴリ
