[go: nahoru, domu]
コンテンツにスキップ

「アプリケーションプログラミングインタフェース」の版間の差分

出典: フリー百科事典『ウィキペディア（Wikipedia）』
履歴の双方向閲覧
← 古い編集新しい編集 →
削除された内容 追加された内容
ビジュアルウィキテキスト
記載が発散しておりライブラリーの説明と混在しているため現実に使われている用語集のAPIに基づいた狭義のAPIの説明に変更しました。
タグ: サイズの大幅な増減 ビジュアルエディター
1行目: 1行目:
{{WikipediaPage|ウィキペディアなど、MediaWikiに対して使えるAPIについては、[[mw:API:Main page/ja|MediaWikiの解説ページ]]をご覧ください。}}
{{WikipediaPage|ウィキペディアなど、MediaWikiに対して使えるAPIについては、[[mw:API:Main page/ja|MediaWikiの解説ページ]]をご覧ください。}}
'''アプリケーションプログラミングインタフェース'''（'''{{Lang|en|API}}'''、{{Lang-en-short|Application Programming Interface}}）とは、[[ソフトウェアコンポーネント]]が互いにやりとりするのに使用する[[インタフェース (情報技術)|インタフェース]]の仕様である。APIには、[[サブルーチン]]、[[データ構造]]、[[クラス (コンピュータ)|オブジェクトクラス]]、変数などの仕様が含まれる。APIには様々な形態があり、[[POSIX]]のような国際規格、[[マイクロソフト]]の[[Windows API]]のようなベンダーによる文書、プログラミング言語の[[ライブラリ]]（例えば、[[C++]]の[[Standard Template Library]]や{{仮リンク|Java API一覧|en|List of Java APIs|label=Java API}}など）がある。
'''アプリケーションプログラミングインタフェース'''（'''{{Lang|en|API}}'''、{{Lang-en-short|Application Programming Interface}}）とは、公義の意味では[[ソフトウェアコンポーネント]]が互いにやりとりするのに使用する[[インタフェース (情報技術)|インタフェース]]の仕様である。APIには、[[サブルーチン]]、[[データ構造]]、[[クラス (コンピュータ)|オブジェクトクラス]]、変数などの仕様が含まれる。APIには様々な形態があり、[[POSIX]]のような国際規格、[[マイクロソフト]]の[[Windows API]]のようなベンダーによる文書、プログラミング言語の[[ライブラリ]]（例えば、[[C++]]の[[Standard Template Library]]や{{仮リンク|Java API一覧|en|List of Java APIs|label=Java API}}など）がある。商業的に使われる狭義の意味ではOSやミドルウェアやWebサービス等サービスを利用するアプリケーション(Application)を作成する(Programming)ためのインターフェース(Interface)である。<ref>https://www.ibm.com/support/knowledgecenter/ja/SS4SVW_2.0.0/com.ibm.zosconnect.doc/backmatter/glossary.html#glossary__api</ref><ref>https://developer.mozilla.org/ja/docs/Glossary/API</ref><ref>http://www.ocn.ne.jp/support/words/abc/API.html</ref><ref>https://www.synergy-marketing.co.jp/glossary/api/</ref>こちらの意味ではStandard Template Libraryなど言語の標準ライブラリーは含まない。


APIは[[Application Binary Interface]] (ABI) とは異なる。APIは[[ソースコード]]ベースだが、ABIはバイナリインタフェースである。例えば、POSIXはAPIだが、[[Linux Standard Base]] (LSB) はABIである<ref>{{Cite web |first=Nick |last=Stoughton |url= http://c59951.r51.cf2.rackcdn.com/4818-1030-standards2004.pdf |title=Update on Standards |publisher=[[USENIX]] |format=PDF |year=2005 |month=April |accessdate=2009-06-04}}</ref>（LSBはいろいろな規定の集合なので、正確には「LSBには、ABIにまで踏み込んでいる部分もある」）。
APIは[[Application Binary Interface]] (ABI) とは異なる。APIは[[ソースコード]]ベースだが、ABIはバイナリインタフェースである。例えば、POSIXはAPIだが、[[Linux Standard Base]] (LSB) はABIである<ref>{{Cite web |first=Nick |last=Stoughton |url= http://c59951.r51.cf2.rackcdn.com/4818-1030-standards2004.pdf |title=Update on Standards |publisher=[[USENIX]] |format=PDF |year=2005 |month=April |accessdate=2009-06-04}}</ref>（LSBはいろいろな規定の集合なので、正確には「LSBには、ABIにまで踏み込んでいる部分もある」）。


== 概要 ==
== 概要 ==
ここでは狭義のAPIを説明する。前述のとおりAPIはサービスがサービスを利用するアプリケーションに提供するためのインターフェースである。APIの重要な役割りはサービス提供者が公式に仕様を定義し管理している操作方法(インターフェース)を提供することである。APIは多くの場合アプリケーションを構築する言語と同じ言語のライブラリーとして(HTTPやXMLなどを組み合わせたプロトコル形式の場合もある)提供され、サービス開発者によって提供・管理される。アプリケーションがサービスを利用するにはAPIを無視してサービスの現在の実装に依存した方法で利用することもできるが、サービス提供者はアプリケーションがAPI以外の仕様に依存していることは認知しておらずAPI以外の仕様が永続的に維持されることも保証しない。バグ修正などで少しでもサービスに変更があればAPIを利用しないアプリケーションはたちまち動かなくなってしまう。アプリケーションがサービスを操作するにあたりAPIにだけ依存することでこのような永続性の問題を防ぐことができるのである。なおAPIを供えたサービスとして代表的なOSにWindowsやiOSがあるが、これらには俗に'''隠しAPI'''や'''プライベートAPI'''等とよばれるものが存在した。これらはサービス提供者が公式に提供している機能ではなくAPIではない。これらの機能を使ったアプリケーションの将来は保証されることはない。
APIは、[[アプリケーションソフトウェア|アプリケーション]]から利用できる、[[オペレーティングシステム]]や[[プログラミング言語]]で用意された[[ライブラリ]]などの機能の入り口となるものである。主に、[[ファイル (コンピュータ)|ファイル]]制御、ウインドウ制御、[[画像]]処理、文字制御などのための[[サブルーチン|関数]]として提供されることが多い。


=== ライブラリーとAPI ===
つまり、簡単にいえば、アプリケーションをプログラムするにあたって、プログラムの手間を省くため、もっと簡潔にプログラムできるように設定されたインターフェースの事である。
APIは[[関数 (プログラミング)|関数]]、[[プロシージャ]]、[[変数 (プログラミング)|変数]]や[[データ構造]]といったライブラリーによって実装されることが多いが狭義のAPIではライブラリーとAPIは同一ではない。ライブラリー形式ではなくプロトコル形式で提供されるという理由もあるが、同じライブラリーである場合も同一視せず区別する必要があるという理由がある。例えば関数であればサービスにより提供される関数はAPI関数と呼ぶが、API関数を利用して構築された関数はAPIではないためライブラリー関数と呼ぶ。ライブラリー関数は直接サービスと関係ないか、APIを使って構築されておりサービスを利用する上で必須ではない。逆にAPI関数の存在は必須である。例えばCのライブラリー関数であるfwrite<ref>https://www.ibm.com/support/knowledgecenter/ja/SSLTBW_2.2.0/com.ibm.zos.v2r2.cbcpx01/write.htm</ref>はAPI関数であるWriteFile<ref>https://msdn.microsoft.com/ja-jp/library/cc429856.aspx</ref>を使って実装されておりOS間の移植性を考えなければWriteFileで代替できる。

APIを使うことで[[ソフトウェア|コンピュータソフトウェア]]が他のソフトウェアと広義の意味で通信しあうことができる。また低レベルな（機械寄りのプログラム言語を使う）ソフトウェアと高レベルな（人間寄りのプログラム言語を使う）ソフトウェアの間の関係をより[[抽象化 (計算機科学)|抽象化]]するための方法である。APIの目的の一つは、ウィンドウやアイコンを描画するというような共通して使える機能（関数）を提供することである。そのような機能を使えば、プログラマーが一から百まで全部コーディングしなくても済むようになる。API自身は抽象的なものだが、APIを提供しているソフトウェアはそのAPIの'''実装'''と呼ばれる。

例えば画面に「{{Lang|en|Hello World}}」と表示させる仕事を考えると：
* 全部自分でやろうとすると
*# 画用紙に「{{Lang|en|Hello World}}」という文字を書く。
*# それを白と黒の四角いマスで表現したデータを作る。
*# [[CPU]]がそのデータを[[ディスプレイアダプター]]の[[VRAM|フレームバッファ]]に格納するプログラムを作成する。
*# [[ビデオカード|グラフィックカード]]を設定して、フレームバッファから正しく信号が生成されるようにする。
* [[オペレーティングシステム]] ('''OS''') を使うと
*# OSから提供される「[[フォント]]」という[[データ構造]]を[[メモリ]]に読み込む。
*# OSに空の[[ウィンドウ]]を表示させる。
*# OSに「{{Lang|en|Hello World}}」という文字列をウィンドウに描画させる。
* OSの機能を使う[[アプリケーションソフトウェア|アプリケーション]]を使うと
*#「{{Lang|en|Hello World}}」と書いた[[HyperText Markup Language|HTML]]ドキュメントを作成し、[[Mozilla Firefox]]や[[Internet Explorer]]などの[[ウェブブラウザ]]に表示させる。

明らかに最初のやり方は手間がかかり、加えて相当な量の情報を渡さなくてはならないため実用的ではない。下に行くほどより簡単になっており、3つ目のやり方になると、「{{Lang|en|Hello World}}」とタイプすればいいぐらいの手間になる。

しかし高レベルなAPIには柔軟性がないことがある。例えば[[ウェブブラウザ]]で文字を点滅させながら円を描くように回転させることは難しいが、低レベルなAPIを使えばもっと簡単に実現できる。APIの簡潔さをとるか柔軟性をとるかは十分に[[トレードオフ]]を考慮する必要がある。

== APIの概念 ==
APIは家の電気と同じように[[コンピュータ]]にとって非常に重要である。自分の家だろうが、友人の家だろうが、[[パン]]を焼きたい時には[[トースター]]を[[配線用差込接続器|コンセント]]につなぐ。これはどちらの家でもコンセントという標準化されたインターフェースを備えているからである。もしコンセントがなければ、人は[[発電所]]までトースターを持参してパンを焼きにいかなくてはならなくなる。ヨーロッパのトースターは[[変圧器]]がなければ、アメリカでは動かないのと同じように、[[Microsoft Windows|Windows]]用に書かれたプログラムは、[[Wine]]などの[[UNIX]]との仲立ちをしてくれるAPI[[アダプター]]がなければUNIX上では動かないし、同様に[[UNIX]]用に書かれたプログラムは[[Cygwin]]などのソフトウェアを用いないとWindows上では動作しない。

APIにはさまざまな設計モデルがある。実行速度を考慮した[[インタフェース (情報技術)|インタフェース]]は通常、[[関数 (プログラミング)|関数]]、[[プロシージャ]]、[[変数 (プログラミング)|変数]]や[[データ構造]]から構成される。また例えば[[ECMAScript]]の構文を解析するための[[インタプリタ]]であることもある。良いAPIは[[ブラックボックス]]であり、良い抽象化層であると言える。すなわち[[プログラマ]]はそのAPIの機能がより低レベルのAPIとどんな関係をもっているのかを知る必要がないのである。それはまた、そのAPIを使用しているコードを壊すことなく、APIの機能を再設計したり、改良したりすることを可能にしている。

使用料などを求められないAPIを「オープン」なAPIと言う。[[フリーソフトウェア]]で提供されるAPIはオープンなので、誰でもソフトウェアのソースを見たり、APIの実装を理解することができる。普通は、信頼ある組織からAPIの「[[リファレンス実装]]」が提供される（例えば[[Microsoft Windows|Windows]]の[[Windows API]]）。それに新たな機能を追加することもできる。例えば、Windows APIのほとんどは[[Wine]]というソフトウェアとして[[UNIX]]システムに提供されている。


== 詳細 ==
== 詳細 ==
ひとつのAPIは特定の1つのタスクを実行する方法を記述している。[[C言語]]などの[[手続き型プログラミング|手続き型言語]]では、[[サブルーチン]]呼び出しによって実際の動作が行われる。したがって、APIは一般にそれが提供するあらゆる[[サブルーチン|関数/ルーチン]]について記述している。例えば <code>math.h</code> という[[C言語]]用[[ヘッダファイル]]は数学的処理のためのC言語ライブラリ（通常 [[libm|<code>libm</code>]] と呼ばれる）で利用可能な数学関数の[[関数プロトタイプ]]の定義を含んでいる。すなわちこのファイルは対応するライブラリに含まれる関数群の「使い方」を記述していると言える。[[関数プロトタイプ]]は、関数名、関数の戻り値のデータ型、引数の個数とそれぞれのデータ型を示す。関数がどう動作するかは、より詳細に人間が読める形で記述され、本または[[manページ]]のような電子形式で提供される。例えば、[[UNIX]]システムのコマンド <code>man 3 sqrt</code> は関数 <code>sqrt</code> について次のような形式で説明を表示する。
<source lang="C">
SYNOPSIS
#include <math.h>
double sqrt(double X);
float sqrtf(float X);
DESCRIPTION
DESCRIPTION
sqrt computes the positive square root of the argument. ...
RETURNS
On success, the square root is returned. If X is real and positive...
</source>

これの意味するところは、その関数が正の[[浮動小数点数]]（[[単精度]] (float) または[[倍精度]] (double)）の平方根を求め、それを浮動小数点数として返すものだということである。したがって、この場合のAPIは、C言語が使用する[[ヘッダファイル]]群と人間が読める形のmanページでの説明で提供されていることになる。

=== APIドキュメンテーション ===
{{Main|ソフトウェアドキュメンテーション}}
多くのプログラム開発環境はAPIについての文書をデジタル形式で提供する仕組みを用意している。例えば、[[Perl]]には[[Plain Old Documentation|perldoc]]というツールがある。
<source lang="perl">
$ perldoc -f sqrt
sqrt EXPRs
sqrt #Return the square root of EXPR. If EXPR is omitted, returns
#square root of $_. Only works on non-negative operands, unless
#you've loaded the standard Math::Complex module.
</source>

[[Python]]には{{仮リンク|pydoc|en|pydoc}}というツールがある。

<source lang="python">
$ pydoc math. sqrt
Help on built-in function sqrt in math:
math. sqrt = sqrt(...)
sqrt(x)
Return the square root of x.
</source>

[[Ruby]]には <code>ri</code> というツールがある。
<source lang="ruby">
$ ri Math::sqrt
------------------------------------------------------------- Math::sqrt
Math.sqrt(numeric) => float
------------------------------------------------------------------------
Returns the non-negative square root of _numeric_.
</source>

[[Java]]は[[HyperText Markup Language|HTML]]形式のページを生成する[[Javadoc]]がある。[[マイクロソフト]]では、同社の各種言語（[[Microsoft Visual C++|Visual C++]]、[[C Sharp|C#]]、[[Microsoft Visual Basic|Visual Basic]]、[[F Sharp|F#]]など）についてのAPI文書を[[Microsoft Visual Studio|Visual Studio]]のヘルプシステムに埋め込む形で提供している。

=== オブジェクト指向言語におけるAPI ===
[[オブジェクト指向プログラミング|オブジェクト指向言語]]では、APIには通常[[クラス (コンピュータ)|クラス]]群の定義が含まれ、それらクラスの動作についての説明が含まれる。この抽象概念は公開されている実際の機能と対応しており、クラス群の[[メソッド (計算機科学)|メソッド]]（あるいはより一般的には、公開されているメソッド群だが、フィールド、定数、入れ子オブジェクト、enumなども公開されていれば含まれる）によって実装されている。

この場合のAPIは、クラス群が公開する全メソッドの総体と理解することができる（これを一般にクラスインタフェースと呼ぶ）。すなわち、APIがメソッド群を規定し、それによってクラス定義から得られるオブジェクトとやりとりすることになる。

さらに一般化すれば、APIとはクラス定義から得られるあらゆるオブジェクトの集合体であり、それらのとりうる振る舞いの集合体である。結局公開されたメソッド群を通して使用するわけだが、APIの意味を考えたとき、メソッドはオブジェクトがどう振る舞うかの「技術的詳細」に過ぎない。

例えば、[[スタック]]を表現したクラス <code>Stack</code> はスタックにアイテムを追加する <code>push()</code> とスタックのトップからアイテムを取り出す <code>pop()</code> という2つのメソッドを公開するだろう。

この場合のAPIは <code>pop()</code> と <code>push()</code> という2つのメソッドと解釈することもできるし、より一般的にはスタックの振る舞いを実装した <code>Stack</code> という型のアイテムを使用できるという「考え方」でもある。後者の解釈の方が[[オブジェクト指向]]の精神にふさわしい。

この概念を推し進めると、API内のクラスインタフェースに全くメソッドが存在せず、単に振る舞いだけが定義されているという地点にまで到達する。例えば、[[Java]]や[[LISP]]のAPIには <code>Serializable</code> というインタフェースがある。これは[[マーカーインタフェース]]であり、それぞれのクラスがどう[[シリアライズ]]するかを実装しなければならない。これは公開されたメソッドを持つことを要求するわけではなく、むしろ任意の時点でセーブ（シリアライズ）できる表現を持つことを、そのインタフェースを実装する任意のクラスに要求する（外部リソースへのリンクを持たない単純なデータしか持たないクラスでは常に成り立つが、ファイルや遠隔システムや外部デバイスへのオープンコネクションを持つ場合はその限りではない）。

同様に、[[並行計算|並行]]（[[スレッド (コンピュータ)|マルチスレッド]]）環境におけるオブジェクトの振る舞いは、実装されたインタフェースに属する特定のメソッド群によっては必ずしも決定されないが、依然としてそのクラスのオブジェクトについてのAPIに属しており、文書によって説明されるべきである<ref>{{Cite book |first= Joshua |last= Bloch |title= Effective Java (2nd edition) |publisher= Addison-Wesley |pages= 259–312 |year= 2008 |isbn= 978-0-321-35668-0}}</ref>。

そういった意味で、オブジェクト指向言語におけるAPIは、主にクラスメソッド群で実現されるオブジェクトの振る舞いのセットを定義したものと言える。

そのような言語でも、APIはライブラリの形で配布される。例えば、Javaのライブラリは開発者が新たなJavaプログラムを開発する際に使用する[[Java Development Kit|JDK]]という形で提供されるAPIのセットを含む。JDKには[[Javadoc]]形式で生成されたAPIドキュメンテーションが含まれている。

APIに関する文書の品質はAPIの使いやすさを左右し、そのAPIの成功を決定付けることが多い。

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


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

=== 仮想機械を通したAPIの共有と再利用 ===
1つの[[仮想機械]]で動作する複数の言語は、APIを共有できる。例えば、[[共通言語ランタイム]]で動作する言語群や[[Java仮想マシン]]で動作する言語群がある。

その場合、中間的な[[バイトコード]]と[[束縛 (情報工学)|言語束縛]]を使って特定言語から抽象化するという[[仮想機械]]の特徴により、言語間の相互運用が可能となる。

これにより、既存のライブラリ群とそのAPIについて、[[コードの再利用]]の可能性が大きくなる。


== ウェブAPI ==
== ウェブAPI ==

2018年1月1日 (月) 09:35時点における版

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

アプリケーションプログラミングインタフェース（API、英: Application Programming Interface）とは、公義の意味ではソフトウェアコンポーネントが互いにやりとりするのに使用するインタフェースの仕様である。APIには、サブルーチン、データ構造、オブジェクトクラス、変数などの仕様が含まれる。APIには様々な形態があり、POSIXのような国際規格、マイクロソフトのWindows APIのようなベンダーによる文書、プログラミング言語のライブラリ（例えば、C++のStandard Template LibraryやJava API（英語版）など）がある。商業的に使われる狭義の意味ではOSやミドルウェアやWebサービス等サービスを利用するアプリケーション(Application)を作成する(Programming)ためのインターフェース(Interface)である。[1][2][3][4]こちらの意味ではStandard Template Libraryなど言語の標準ライブラリーは含まない。

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

概要

ここでは狭義のAPIを説明する。前述のとおりAPIはサービスがサービスを利用するアプリケーションに提供するためのインターフェースである。APIの重要な役割りはサービス提供者が公式に仕様を定義し管理している操作方法(インターフェース)を提供することである。APIは多くの場合アプリケーションを構築する言語と同じ言語のライブラリーとして(HTTPやXMLなどを組み合わせたプロトコル形式の場合もある)提供され、サービス開発者によって提供・管理される。アプリケーションがサービスを利用するにはAPIを無視してサービスの現在の実装に依存した方法で利用することもできるが、サービス提供者はアプリケーションがAPI以外の仕様に依存していることは認知しておらずAPI以外の仕様が永続的に維持されることも保証しない。バグ修正などで少しでもサービスに変更があればAPIを利用しないアプリケーションはたちまち動かなくなってしまう。アプリケーションがサービスを操作するにあたりAPIにだけ依存することでこのような永続性の問題を防ぐことができるのである。なおAPIを供えたサービスとして代表的なOSにWindowsやiOSがあるが、これらには俗に隠しAPIやプライベートAPI等とよばれるものが存在した。これらはサービス提供者が公式に提供している機能ではなくAPIではない。これらの機能を使ったアプリケーションの将来は保証されることはない。

ライブラリーとAPI

APIは関数、プロシージャ、変数やデータ構造といったライブラリーによって実装されることが多いが狭義のAPIではライブラリーとAPIは同一ではない。ライブラリー形式ではなくプロトコル形式で提供されるという理由もあるが、同じライブラリーである場合も同一視せず区別する必要があるという理由がある。例えば関数であればサービスにより提供される関数はAPI関数と呼ぶが、API関数を利用して構築された関数はAPIではないためライブラリー関数と呼ぶ。ライブラリー関数は直接サービスと関係ないか、APIを使って構築されておりサービスを利用する上で必須ではない。逆にAPI関数の存在は必須である。例えばCのライブラリー関数であるfwrite[6]はAPI関数であるWriteFile[7]を使って実装されておりOS間の移植性を考えなければWriteFileで代替できる。

詳細

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

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

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

APIとプロトコル

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

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

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

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

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

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

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

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

ウェブAPI

詳細は「Webサービス」を参照

ウェブ開発においては、APIは一般にHTTP要求メッセージ群とXMLまたはJSON形式などの応答メッセージの構造定義で構成される。「ウェブAPI」はWebサービスと事実上同義だが、Web 2.0と呼ばれる最近の傾向では、SOAPベースからREST風の直接的通信へと変化している[10]。ウェブAPIはマッシュアップと呼ばれる技法で複数のサービスを組み合わせて新たなアプリケーションとすることを可能にする[11]。

ウェブによるコンテンツ共有

APIを公表する慣習により、ウェブコミュニティにはコミュニティ間やアプリケーション間でコンテンツとデータを共有するオープンアーキテクチャが発展していった。そのため、ある場所で作成されたコンテンツはウェブ上の様々な場所で盛んにポストされ更新される。

  1. 写真はFlickrやPhotobucketといったサイトからFacebookやMyspaceといったソーシャルネットワークサイトに共有される。
  2. コンテンツは埋め込むこともできる。例えば、SlideShareにあるプレゼン資料をLinkedInのプロファイル情報に埋め込むことができる。
  3. TwitterのつぶやきをFacebookの投稿にも同時に反映させるAPIもある。
  4. 動画コンテンツも別のホスト上のサイトに埋め込むことができる。
  5. ウェブコミュニティにおけるユーザー情報を外部アプリケーションと共有させることができ、アプリケーションの更新をウェブ側から働きかけるなどの機能もオープンなAPIで実現されている。好例としてFacebookプラットフォーム（英語版）やOpenSocialプラットフォームがある。

実装

POSIX標準は、様々な一般的コンピューティング機能を各種システム上で実装できるよう考慮したAPIを定義している。例えば、macOSやBSD系システムで実装されている。ただし、POSIX準拠のプログラムを別のPOSIX準拠のプラットフォームで実行するには、再コンパイルが必要である。一方、互換APIの場合、そのAPIを実装したシステムならどこでも同じオブジェクトファイルがそのまま実行可能である。これはソフトウェア業者にもユーザーにも有益であり、業者は互換APIが実装されていれば新システムが登場しても製品を修正せずに済むし、ユーザーも古いソフトウェアを新システムにインストールできる。ただし、それには一般に各種ライブラリが必要なAPI群を実装している必要がある。

マイクロソフトはAPIの後方互換性の維持を心がけており、特にWindows API (Win32) ライブラリは古いアプリケーションが新しいWindows上でも動作できるよう互換モードを備えている[12]。

Unix系OSでは、相互に関連はあるが非互換なOS群が同一ハードウェア上で動作している。ソフトウェア業者が同一バイナリで各種OSに対応できるようAPIとABIを共通化する試みがなされてきたが、いずれも失敗に終わっている。そのような試みとしてLinuxではLinux Standard Baseがある。BSD系OSも各種あるが、互換性のレベルは様々である。

公開の方針

APIの公開に関しては2つの一般的な方針がある。

  1. 自社のAPIを厳重に秘匿する。
    例えばソニーはライセンスをもった開発者にしかプレイステーションの公開APIを利用できないようにしている。なぜならプレイステーションのゲームを開発できる人の数を制限したほうが、より多くの利益をあげられるからである。これはAPIの実装を売ることで利益を上げるわけではない会社の典型的な例である。（ソニーの場合は、ゲーム開発時のAPIのライセンス料によって利益を上げようとしたがうまくいかず、プレイステーション用コンソールの販売を中止している。）
  2. 自社のAPIを広く普及させる。
    例えばマイクロソフトは計画的にAPIに関する情報を公開しているので、誰でも簡単にWindowsプラットフォーム用のソフトウェアを作成することができる。これはAPIの実装を販売して利益をあげる会社の例である。OSなどのAPIは、いくつかのコードに分割され、ライブラリとして実装されており、OSと一緒に配布される。OSと一緒に配布されるWindowsのAPIは誰でも使うことができる。また直接アプリケーションの中に統合される必要があるAPIもある。

この2つの方針の中間もある。

リバースエンジニアリングと著作権

互換性のためのAPIを作成するためにそのAPIの実装を解析することは一般的に合法である。この手法は相互運用性のためのリバースエンジニアリングと呼ばれる。しかしAPIそのものとは異なり、APIの実装には著作権が存在するため、リバースエンジニアリングする前には著作権侵害の問題が生じないよう、十分注意する必要がある。また、使おうとしているAPIに、特許保持者の許可がなければ使えない特許技術が許可なく含まれていたら、それは特許権侵害になりうる。（ただし、これはリバースエンジニアリングに限られた話ではなく、APIを利用するプログラムにも全般的に言えることである。）

2010年、米オラクルはGoogleがJavaの新たな実装をAndroidの一部として配布したとして、Googleを訴えた[13]。GoogleはJava APIを複製する許可をとっていなかったが、類似の許可はOpenJDKプロジェクトに与えられていた。これに対して、地方裁判所はAPIは著作権法の対象外であるとする判断を下したものの、控訴裁では保護対象であるとされ、最終的に2015年、最高裁によりアメリカ合衆国内ではAPIにも著作権があるとの判断が確定した[14][15][16]。ただし著作権があってもフェアユースの下に利用可能かについては、2015年現在継続して審理されている。

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

APIの例

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

複数の高水準言語での使用を意図したAPIは、文法的・意味的に各言語に適したインタフェースをAPIに自動的にマッピングする機能を提供している。これを言語束縛と呼び、それ自体もAPIである。その目的は、そのAPIに要求される機能のほとんどをカプセル化するため、各言語に薄い層を設けることである。

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

  • SWIG - オープンソースの多言語間のインタフェースジェネレータ（通常はC/C++からスクリプト言語へのインタフェースを生成）
  • F2PY:[18] - FortranからPythonへのインタフェースジェネレータ

脚注

[脚注の使い方]
  1. ^ https://www.ibm.com/support/knowledgecenter/ja/SS4SVW_2.0.0/com.ibm.zosconnect.doc/backmatter/glossary.html#glossary__api
  2. ^ https://developer.mozilla.org/ja/docs/Glossary/API
  3. ^ http://www.ocn.ne.jp/support/words/abc/API.html
  4. ^ https://www.synergy-marketing.co.jp/glossary/api/
  5. ^ Stoughton, Nick (2005年4月). “Update on Standards” (PDF). USENIX. 2009年6月4日閲覧。
  6. ^ https://www.ibm.com/support/knowledgecenter/ja/SSLTBW_2.2.0/com.ibm.zos.v2r2.cbcpx01/write.htm
  7. ^ https://msdn.microsoft.com/ja-jp/library/cc429856.aspx
  8. ^ Fowler, Martin. “Inversion Of Control”. 2012年10月18日閲覧。
  9. ^ “API vs Protocol”. 2012年10月18日閲覧。
  10. ^ 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日閲覧。
  11. ^ 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 
  12. ^ Microsoft. “Getting older programs to run on Windows XP”. Microsoft. 2012年10月18日閲覧。
  13. ^ “Oracle and the End of Programming As We Know It”. DrDobbs (2012年5月1日). 2012年5月9日閲覧。
  14. ^ Josh Lowensohn (2012年5月23日). “Jury clears Google of infringing on Oracle's patents”. ZDNet. 2012年5月25日閲覧。
  15. ^ Joe Mullin (2012年5月31日). “Google wins crucial API ruling, Oracle’s case decimated”. Ars Technica. 2012年6月1日閲覧。
  16. ^ “米最高裁がGoogleの訴えを却下、OracleとのJava著作権訴訟で”. ITPro (2015年6月30日). 2015年7月1日閲覧。
  17. ^ 松下正. “知的財産権（特許・商標・著作権）の基礎講座”. 知的財産権（特許・商標・著作権）の基礎講座. 2015年7月1日閲覧。
  18. ^ “F2PY.org”. F2PY.org. 2011年12月18日閲覧。

関連項目

ウィキメディア・コモンズには、アプリケーションプログラミングインタフェースに関連するカテゴリがあります。

外部リンク

概要
カーネル
アーキテクチャ
コンポーネント
プロセス管理
概念
スケジューリング
アルゴリズム
メモリ管理と
リソース保護
ストレージアクセスと
ファイルシステム
一覧
Unix系
その他
その他
「https://ja.wikipedia.org/w/index.php?title=アプリケーションプログラミングインタフェース&oldid=66819845」から取得