Loading article…
アプリケーションプログラミングインターフェース（API ）は、コンピュータ間またはコンピュータプログラム間の接続です。これは、他のソフトウェアにサービスを提供するソフトウェアインターフェースの一種です。[ 1 ] [ 2 ]このような接続またはインターフェースの構築方法を記述した文書または標準は、API仕様と呼ばれます。この標準を満たすコンピュータシステムは、APIを実装または公開していると言われます。APIという用語は、仕様または実装のいずれかを指す場合があります。
ユーザーインターフェースがコンピュータと人間を接続するのに対し、アプリケーションプログラミングインターフェースはコンピュータやソフトウェア同士を接続します。これは、ソフトウェアに組み込むコンピュータプログラマ[ 2 ]以外の人間（エンドユーザー）が直接使用することを想定していません。APIは多くの場合、プログラマが利用できるツールやサービスとして機能するさまざまな部分で構成されています。これらの部分のいずれかを使用するプログラムまたはプログラマは、そのAPIの部分を呼び出すと言われます。APIを構成する呼び出しは、サブルーチン、メソッド、リクエスト、またはエンドポイントとも呼ばれます。API仕様はこれらの呼び出しを定義しており、つまり、それらの使用方法や実装方法を説明しています。
APIの主な目的の一つは、システムの内部動作の詳細を隠蔽し、プログラマーにとって有用な部分のみを公開し、内部動作の詳細が後で変更された場合でも一貫性を維持することです。APIは特定のシステムペア向けにカスタム構築される場合もあれば、多くのシステム間での相互運用性を可能にする共有標準となる場合もあります。
APIという用語は、インターネットで接続されたコンピュータ間の通信を可能にするWeb APIを指す場合によく使用されます[ 3 ] 。プログラミング言語、ソフトウェアライブラリ、コンピュータオペレーティングシステム、コンピュータハードウェア用のAPIもあります。APIは1940年代に誕生しましたが、この用語が登場したのは1960年代から70年代になってからです。
API は、ソフトウェア システムを外部からの相互作用に開放します。これにより、2 つのソフトウェア システムが、相互に合意した信号を使用して境界(インターフェース)を介して通信できるようになります。 [ 4 ]つまり、API はソフトウェア エンティティ同士を接続します。ユーザー インターフェースとは異なり、API は通常ユーザーには見えません。これは、マシン間通信に使用されるソフトウェア システムの「内部」部分です。[ 5 ]
適切に設計されたAPIは、ソフトウェアまたはソフトウェア開発者が必要とするオブジェクトまたはアクションのみを公開します。不要な詳細は隠蔽されます。この抽象化によりプログラミングが簡素化されます。[ 6 ]
API を使用したソフトウェアの構築は、レゴブロックなどの積み木玩具の使用に例えられます。ソフトウェアサービスやソフトウェアライブラリはブロックに相当し、API を介して結合することで新しいソフトウェア製品を構成できます。[ 7 ]この結合プロセスは統合と呼ばれます。[ 4 ]
例えば、API を提供する気象センサーを考えてみましょう。特定のメッセージがセンサーに送信されると、センサーは現在の気象状況を検出し、気象レポートで応答します。センサーを起動するメッセージは API呼び出しであり、気象レポートは API応答です。[ 8 ]天気予報アプリは、地理的な領域全体から気象データを収集する複数の気象センサー API と統合する可能性があります。
APIはしばしば契約に例えられます。それは、APIを提供するサービスプロバイダーと、それに依存するソフトウェア開発者との間の合意を表します。APIが安定している、または予測可能な方法でのみ変更される場合、開発者のAPIに対する信頼が高まります。これにより、APIの使用が増加する可能性があります。[ 9 ]
APIという用語は当初、アプリケーション プログラムとして知られるエンド ユーザー向けプログラムのインターフェースのみを指していました。この起源は今でも「アプリケーション プログラミング インターフェイス」という名称に反映されています。今日では、この用語はユーティリティ ソフトウェアやハードウェア インターフェイスも含む、より広い意味を持つようになっています。[ 11 ]
API の概念は、その用語自体よりもずっと古い。イギリスのコンピュータ科学者モーリス・ウィルクスとデイビッド・ウィーラーは、 1940 年代に初期のコンピュータであるEDSAC用のモジュール型ソフトウェアライブラリに取り組んでいた。このライブラリのサブルーチンは、ファイルキャビネットに整理されたパンチ紙テープに保存されていた。このキャビネットには、ウィルクスとウィーラーが「ライブラリカタログ」と呼んだ、各サブルーチンに関するメモと、それをプログラムに組み込む方法も含まれていた。今日では、このようなカタログは、プログラマが必要とする各サブルーチンの使用方法（または「呼び出し」方法）をプログラマに指示するため、API（または API 仕様、API ドキュメント）と呼ばれるだろう。[ 11 ]
ウィルクスとウィーラーの著書『電子デジタルコンピュータのためのプログラムの準備』には、初めて公開されたAPI仕様が含まれています。ジョシュア・ブロックは、APIは発明されたというより発見された概念であるため、ウィルクスとウィーラーは「潜在的に」APIを発明したと考えています。[ 11 ]
「アプリケーション プログラム インターフェイス」（-ing接尾辞なし）という用語は、1968 年のAFIPS会議で発表された「リモートコンピュータ グラフィックスのためのデータ構造と技術」という論文で初めて記録されました。[ 13 ] [ 11 ]この論文の著者は、アプリケーション（この場合はグラフィックス プログラム）とコンピュータ システムの残りの部分との相互作用を説明するためにこの用語を使用しています。一貫したアプリケーション インターフェイス（Fortranサブルーチン呼び出しで構成）は、プログラマがグラフィックス ディスプレイ デバイスの特異性に対処する必要がなくなり、コンピュータまたはディスプレイが交換された場合にハードウェアの独立性を提供することを目的としていました。 [ 12 ]
この用語は、CJ Date [ 14 ]が1974 年の論文「リレーショナルとネットワークのアプローチ：アプリケーション プログラミング インターフェイスの比較」でデータベースの分野に導入しました。[ 15 ] API は、データベース管理システムのANSI/SPARC フレームワークの一部になりました。このフレームワークは、アプリケーション プログラミング インターフェイスをクエリ インターフェイスなどの他のインターフェイスとは別に扱いました。1970 年代のデータベース専門家は、これらの異なるインターフェイスを組み合わせることができることに気づきました。十分に豊富なアプリケーション インターフェイスは、他のインターフェイスもサポートできます。[ 10 ]
この観察結果から、アプリケーションプログラミングだけでなく、あらゆる種類のプログラミングをサポートするAPIが生まれました。1990年までに、技術者のカール・マラマッドはAPIを「特定のタスクを実行するためにプログラマーが利用できる一連のサービス」と単純に定義しました。[ 16 ]
API の概念は、リモート プロシージャ コールとWeb API の登場により再び拡大しました。1970年代と 80 年代にコンピュータ ネットワークが普及するにつれて、プログラマはローカル コンピュータだけでなく、他の場所にあるコンピュータにあるライブラリも呼び出したいと考えるようになりました。これらのリモート プロシージャ コールは、特にJava言語で十分にサポートされていました。1990 年代には、インターネットの普及に伴い、 CORBA、COM、DCOMなどの標準が、API サービスを公開する最も一般的な方法になろうと競い合いました。[ 17 ]
ロイ・フィールディングが2000年にカリフォルニア大学アーバイン校で発表した博士論文「アーキテクチャスタイルとネットワークベースのソフトウェアアーキテクチャの設計」では、表現状態転送（REST）の概要が示され、フィールディングが従来の「ライブラリベース」のAPIと対比させた「ネットワークベースのアプリケーションプログラミングインターフェース」の概念が説明されました。[ 18 ] XMLとJSONのWeb APIは2000年から広く商用化され、2021年現在もその傾向が続いています。Web APIは現在、APIという用語の最も一般的な意味となっています。[ 3 ]
2001 年にティム・バーナーズ＝リーが提唱したセマンティックWeb には、ソフトウェアの動作インターフェースではなく、オープンで分散されたデータインターフェースとして API を再定義する「セマンティック API」が含まれていました。[ 19 ]独自のインターフェースとエージェントはオープンなものよりも広く普及しましたが、データインターフェースとしての API の考え方は定着しました。Web API はあらゆる種類のデータをオンラインで交換するために広く使用されているため、API はインターネット上の通信の大部分を説明する広い用語になりました。[ 17 ]このように使用される場合、API という用語は通信プロトコルという用語と意味が重複します。
ソフトウェアライブラリへのインターフェースは、APIの一種です。APIは「期待される動作」（仕様）を記述・規定するものであり、ライブラリはこの一連のルールを「実際に実装したもの」です。
単一のAPIは、同じプログラミングインターフェースを共有する異なるライブラリという形で、複数の実装（または抽象化された実装）を持つことができる。
APIと実装を分離することで、ある言語で書かれたプログラムが別の言語で書かれたライブラリを使用できるようになります。たとえば、ScalaとJavaは互換性のあるバイトコードにコンパイルされるため、Scala開発者は任意のJava APIを利用できます。[ 20 ]
API の使用方法は、使用するプログラミング言語の種類によって異なります。Luaのような手続き型言語の API は、主にコードの実行、データの操作、エラー処理を行う基本的なルーチンで構成される可能性がありますが、Java のようなオブジェクト指向言語の API は、クラスとそのクラスメソッドの仕様を提供します。[ 21 ] [ 22 ]ハイラムの法則は、「API のユーザーが十分な数いる場合、契約で何を約束しても関係ありません。システムの観測可能な動作はすべて誰かに依存していることになります。」と述べています。[ 23 ]一方、いくつかの研究では、API を使用するほとんどのアプリケーションは、API のごく一部しか使用しない傾向があることが示されています。 [ 24 ]
言語バインディングもAPIの一種です。言語バインディングは、ある言語の機能と能力を別の言語で実装されたインターフェースにマッピングすることで、ある言語で書かれたライブラリやサービスを別の言語での開発時に使用できるようにします。[ 25 ] SWIGやFortranからPythonへのインターフェース生成ツールであるF2PYなどのツールは、このようなインターフェースの作成を容易にします。[ 26 ]
APIはソフトウェアフレームワークと関連付けられることもあります。フレームワークは複数のライブラリに基づいて構築され、それらのライブラリが複数のAPIを実装しますが、通常のAPIの使用とは異なり、フレームワークに組み込まれた動作へのアクセスは、フレームワーク自体に新しいクラスを追加することでその内容を拡張することによって行われます。
さらに、制御の反転や同様のメカニズムにより、プログラム全体の制御フローは呼び出し元の制御から外れ、フレームワークの手に渡る可能性がある。 [ 27 ] [ 28 ]
API は、アプリケーションとオペレーティングシステム間のインターフェースを指定できます。[ 29 ] 例えば、POSIX は、POSIX 準拠のオペレーティングシステム用に書かれたアプリケーションを別の POSIX 準拠のオペレーティングシステム用にコンパイルできるようにすることを目的とした一連の共通 API を指定しています。
LinuxとBerkeley Software Distributionは、POSIX APIを実装しているオペレーティングシステムの例である。[ 30 ]
Microsoft は、特にWindows API (Win32) ライブラリにおいて、後方互換性のある API に強いこだわりを示しており、古いアプリケーションは「互換モード」と呼ばれる実行ファイル固有の設定を使用して新しいバージョンの Windows で実行できます。 [ 31 ] Microsoft の開発者が同社のオペレーティングシステムの内部 API にアクセスできることがどの程度有利なのかは不明です。Technologic Computer Letterの Richard A. Shaffer は1987 年にこの状況を「Microsoft がすべてのバットとフィールドを所有している」野球の試合に例え、[ 32 ] Lotus DevelopmentやAshton-Tateのような大手ベンダーは、小規模なソフトウェア開発者にはなかったMS-DOS 5.0に関する情報を受け取ったと報告されています。 [ 33 ]しかし、Ashton-Tate のEd Esberは 1987 年のインタビューで、Bill Gatesから、開発者は初期の API に基づいてソフトウェアを書き直さなければならないことがあると聞いたと述べています。ゲイツ氏はインタビューの中で、マイクロソフトのApple MacintoshアプリケーションがMS-DOS向けアプリケーションよりも成功したのは、同社がMac OSにもリソースを割く必要がなかったためだと述べている。[ 34 ]
APIはソースコードベースであるのに対し、ABIはバイナリベースであるという点で、アプリケーションバイナリインターフェース（ABI）とは異なります。例えば、POSIXはAPIを提供し、Linux Standard BaseはABIを提供します。[ 35 ] [ 36 ]
リモート API を使用すると、開発者はプロトコルを介してリモート リソースを操作できます。プロトコルとは、言語やプラットフォームに関係なく、さまざまなテクノロジーが連携して動作できるようにする通信の特定の標準です。たとえば、Java データベース接続 API を使用すると、開発者は同じ一連の関数を使用してさまざまなタイプのデータベースにクエリを実行できます。一方、 Java リモート メソッド呼び出しAPI は、Java リモート メソッド プロトコルを使用して、リモートで動作するが開発者からはローカルに見える関数を呼び出すことができます。 [ 37 ] [ 38 ]
したがって、リモートAPIはオブジェクト指向プログラミングにおけるオブジェクト抽象化を維持する上で有用です。プロキシオブジェクト上でローカルに実行されるメソッド呼び出しは、リモートプロトコルを使用してリモートオブジェクト上の対応するメソッドを呼び出し、戻り値としてローカルで使用する結果を取得します。
プロキシオブジェクトの変更は、リモートオブジェクトにも対応する変更をもたらします。[ 39 ]
Web API は、企業と、その資産を使用するアプリケーションとの間で相互作用が行われるための定義済みインターフェースであり、機能プロバイダーを指定し、API ユーザーに対してサービス パスまたは URL を公開するサービス レベル契約(SLA) でもあります。API アプローチは、さまざまなタイプの消費者にサービスを提供するさまざまなアプリケーションに対して、一連のサービスへのプログラム インターフェースを提供することを中心としたアーキテクチャ アプローチです。[ 40 ]
Web開発の文脈で使用される場合、APIは通常、ハイパーテキスト転送プロトコル（HTTP）リクエストメッセージなどの仕様のセットとして定義され、応答メッセージの構造の定義も含まれ、通常は拡張マークアップ言語（XML）またはJavaScriptオブジェクト表記（JSON）形式です。例としては、配送サービスの注文を容易にし、サイト開発者が配送業者の料金表をWebデータベースに入力することなく、現在の配送料金を自動的に含めることができる配送会社のAPIが挙げられます。歴史的に「Web API」は事実上Webサービスと同義でしたが、最近の傾向（いわゆるWeb 2.0）は、シンプルオブジェクトアクセスプロトコル（SOAP）ベースのWebサービスとサービス指向アーキテクチャ（SOA）から、より直接的な表現状態転送（REST）スタイルのWebリソースとリソース指向アーキテクチャ（ROA）へと移行しています。[ 41 ]この傾向の一部は、Webベースのオントロジーエンジニアリング技術を促進する概念であるリソース記述フレームワーク（RDF）へのセマンティックWebの動きに関連しています。 Web API を使用すると、複数の API を組み合わせて、マッシュアップと呼ばれる新しいアプリケーションを作成できます。[ 42 ] ソーシャルメディア分野では、Web API により、Web コミュニティがコミュニティ間やアプリケーション間でコンテンツやデータを共有しやすくなりました。このようにして、1 か所で動的に作成されたコンテンツを、Web 上の複数の場所に投稿および更新できます。[ 43 ]例えば、Twitter の REST API を使用すると、開発者はコア Twitter データにアクセスでき、検索 API を使用すると、開発者は Twitter 検索やトレンド データとやり取りできます。[ 44 ]
API の設計は、その使用に大きな影響を与えます。[ 6 ]情報隠蔽の原則は、モジュールの実装の詳細を隠蔽することでモジュールのユーザーがモジュール内部の複雑さを理解する必要がないようにし、モジュール型プログラミングを可能にするというプログラミング インターフェースの役割を説明しています。 [ 45 ]したがって、API の設計は、ユーザーが期待するツールのみを提供するように試みます。[ 6 ]プログラミング インターフェースの設計は、複雑なソフトウェアの構成であるソフトウェア アーキテクチャの重要な部分です。 [ 46 ]
APIは、テクノロジー企業が統合を行う最も一般的な方法の1つです。APIを提供および使用する企業は、ビジネスエコシステムのメンバーとみなされます。[ 47 ]
API を公開するための主なポリシーは次のとおりです。[ 48 ]
API が公開される際に重要な要素となるのは、「インターフェースの安定性」です。API の変更（例えば、関数呼び出しに新しいパラメータを追加するなど）は、その API に依存するクライアントとの互換性を損なう可能性があります。[ 52 ]
公開されている API の一部が変更される可能性があり、安定していない場合は、特定の API のそのような部分を明示的に「不安定」として文書化する必要があります。たとえば、Google Guavaライブラリでは、不安定で近いうちに変更される可能性がある部分は、 Java アノテーション でマークされています@Beta。[ 53 ]
公開されている API は、その一部が非推奨または廃止されたと宣言することがあります。これは通常、その API の一部が削除または後方互換性のない方法で変更される候補であることを意味します。したがって、これらの変更により、開発者は将来削除またはサポートされなくなる API の一部から移行することができます。[ 54 ]
クライアント コードには、API 設計者が意図していなかった革新的または機会主義的な使用が含まれている可能性があります。言い換えれば、ユーザーベースが大きいライブラリの場合、要素がパブリック API の一部になると、さまざまな方法で使用される可能性があります。[ 55 ] 2020 年 2 月 19 日、Akamai は年次レポート「インターネットの現状」を発表し、世界中の金融サービスにおけるパブリック API プラットフォームを標的とするサイバー犯罪者の増加する傾向を示しました。2017 年 12 月から 2019 年 11 月にかけて、Akamai は 854.2 億件の認証情報侵害攻撃を確認しました。約 20%、つまり 165.5 億件は、API エンドポイントとして定義されたホスト名に対するものでした。これらのうち、4億 7350 万件は金融サービス部門の組織を標的としていました。[ 56 ]
APIドキュメントは、APIが提供するサービスとその利用方法を説明するもので、クライアントが実務上必要とするすべての情報を網羅することを目的としています。
API を使用するアプリケーションの開発と保守には、ドキュメントが不可欠です。[ 57 ] API ドキュメントは従来ドキュメント ファイルに記載されていましたが、ブログ、フォーラム、Q&A ウェブサイトなどのソーシャルメディアでも見つけることができます。[ 58 ]
従来のドキュメントファイルは、Javadoc や Pydoc などの一貫した外観と構造を持つドキュメントシステムを介して提示されることが多い。しかし、ドキュメントに含まれるコンテンツの種類は API ごとに異なる。[ 59 ]
明確化のため、APIドキュメントには、API内のクラスやメソッドの説明、典型的な使用シナリオ、コードスニペット、設計上の根拠、パフォーマンスに関する考察、契約などが含まれる場合がありますが、APIサービス自体の実装の詳細は通常省略されます。ドキュメントは、説明文書、チュートリアル、参考資料など、さまざまな形式をとることができます。また、ガイドや機能など、多様な情報タイプが含まれます。
API の使用方法に関する制限事項もドキュメントに記載されています。たとえば、API 関数のドキュメントには、そのパラメータが null であってはならないこと、関数自体がスレッド セーフではないことなどが記載されている場合があります。[ 60 ] API ドキュメントは包括的である傾向があるため、ドキュメントを最新の状態に保つことは作成者にとって困難であり、ユーザーが注意深く読むことでバグが発生する可能性もあります。[ 52 ]
API ドキュメントには、 Java アノテーションなどのメタデータ情報を追加できます。このメタデータは、コンパイラ、ツール、および実行環境によって、カスタム動作やカスタム処理を実装するために使用できます。[ 61 ]
データ駆動型の方法でAPIドキュメントを生成することが可能です。特定のAPIを使用する多くのプログラムを観察することで、典型的な使用方法や必要な契約および指示を推測できます。[ 62 ]その後、テンプレートを使用して、マイニングされたデータから自然言語を生成できます。
2010年、Oracle Corporationは、Androidオペレーティングシステムに組み込まれたJavaの新しい実装を配布したとしてGoogleを訴えた。[ 63 ] GoogleはJava APIを複製する許可を得ていなかったが、同様のOpenJDKプロジェクトには許可を与えていた。Oracle対Google訴訟において、ウィリアム・アルサップ判事は、APIは米国では著作権で保護できないこと、そしてOracleが勝訴すれば著作権保護が「機能的なシンボルのセット」にまで広く拡大され、単純なソフトウェアコマンドの著作権も認められることになるだろうと判決を下した。
オラクルの主張を認めると、コマンドシステムを実行するコードのバージョンを誰でも著作権で保護できるようになり、それによって他の全員が同じコマンドの全部または一部を実行する異なるバージョンを作成することを禁止することになる。[ 64 ] [ 65 ]
アルサップの判決は2014年に連邦巡回控訴裁判所への上訴で覆されたが、APIのそのような使用がフェアユースに該当するかどうかの問題は未解決のまま残された。[ 66 ] [ 67 ]
2016年、2週間の裁判の後、陪審はGoogleによるJava APIの再実装はフェアユースに該当すると判断したが、Oracleは判決を不服として控訴すると表明した。[ 68 ] Oracleは控訴審で勝訴し、連邦巡回控訴裁判所はGoogleによるAPIの使用はフェアユースに該当しないとの判決を下した。[ 69 ] 2019年、Googleは著作権の有無とフェアユースの判決の両方について米国最高裁判所に上訴し、最高裁判所は審理を受理した。[ 70 ] COVID-19パンデミックのため、この訴訟の口頭審理は2020年10月まで延期された。[ 71 ]
この訴訟は最高裁判所によってグーグルに有利な判決が下された。[ 72 ]
「API」またはその拡張版である「Application Programming Interface」という略語を聞くと、ほとんどの場合、HTTP を使用して JSON または XML 形式の機械可読データへのアクセスを提供するという、現代のアプローチを指しています。これは、単に「Web API」と呼ばれることがよくあります。 API はコンピューティングとほぼ同じくらい長い間存在していましたが、現代の Web API は 2000 年代初頭に形を成し始めました。
1853年、彼はブリュッセルで開催された海事条約で基調講演を行い、気象データの標準化された報告形式を提案した。もし2005年であれば、彼はコンピュータ同士が通信できるようにするための公開APIを提案しただろう。より効率的で正確なデータ収集を可能にするためである。（テキストURL）