API
半保護ページ

アプリケーションプログラミングインターフェース（API ）は、コンピュータ間またはコンピュータプログラム間の接続です。これはソフトウェアインターフェースの一種であり、他のソフトウェアにサービスを提供します。[ 1 ]このような接続またはインターフェースの構築方法を記述した文書または標準は、API仕様と呼ばれます。この標準に準拠したコンピュータシステムは、APIを実装または公開していると言われます。APIという用語は、仕様または実装のいずれかを指す場合があります

コンピュータと人をつなぐユーザーインターフェースとは対照的に、アプリケーションプログラミングインターフェースは、コンピュータまたはソフトウェア同士をつなぎます。これは、それをソフトウェアに組み込むコンピュータプログラマー[ 1 ]以外の人 (エンドユーザー) が直接使用することを意図していません。API は、多くの場合、プログラマーが利用できるツールまたはサービスとして機能する異なる部分で構成されています。これらの部分の 1 つを使用するプログラムまたはプログラマーは、 API のその部分を呼び出すと言われます。API を構成する呼び出しは、サブルーチン、メソッド、リクエスト、またはエンドポイントとも呼ばれます。API 仕様はこれらの呼び出しを定義し、それらを使用または実装する方法を説明します。

APIの目的の一つは、システム内部の動作の詳細を隠蔽し、プログラマーにとって有用な部分のみを公開することで、内部の詳細が後から変更された場合でも一貫性を維持することです。APIは特定のシステムペア向けにカスタム構築される場合もあれば、多くのシステム間の 相互運用性を可能にする共通標準となる場合もあります。

APIという用語は、インターネットで接続されたコンピュータ間の通信を可能にするWeb API [ 2 ]を指すことが多い。プログラミング言語、ソフトウェアライブラリ、コンピュータオペレーティングシステム、コンピュータハードウェア用のAPIも存在する。APIは1940年代に誕生したが、その用語が使われるようになったのは1960年代から70年代になってからである。

目的

APIは、ソフトウェアシステムを外部からのインタラクションに開放します。APIは、2つのソフトウェアシステムが、相互に合意されたシグナルを用いて、境界（インターフェース）を越えて通信することを可能にします。[ 3 ]つまり、APIはソフトウェアエンティティを相互に接続します。ユーザーインターフェースとは異なり、APIは通常、ユーザーからは見えません。これはソフトウェアシステムの「裏側」にある部分であり、マシン間通信に使用されます。[ 4 ]

適切に設計されたAPIは、ソフトウェアやソフトウェア開発者に必要なオブジェクトやアクションのみを公開します。不要な詳細は隠蔽されます。この抽象化により、プログラミングが簡素化されます。[ 5 ]

比喩的に言えば、API は連結ブロックのようにソフトウェアを接続します。

APIを用いたソフトウェア構築は、レゴブロックなどの積み木玩具の使用に例えられます。ソフトウェアサービスやソフトウェアライブラリは、積み木に似ています。これらはAPIを介して結合され、新しいソフトウェア製品を構成することができます。[ 6 ]この結合プロセスは統合と呼ばれます。[ 3 ]

例として、APIを提供する気象センサーを考えてみましょう。特定のメッセージがセンサーに送信されると、センサーは現在の気象状況を検知し、天気予報を返します。センサーを起動するメッセージはAPI呼び出しであり、天気予報はAPI応答です。[ 7 ]天気予報アプリは、複数の気象センサーAPIと統合し、地理的なエリア全体から気象データを収集する可能性があります。

APIはしばしば契約に例えられます。APIは、APIを提供するサービスプロバイダーと、それを利用するソフトウェア開発者という当事者間の合意を表します。APIが安定しているか、予測可能な方法でのみ変更されていれば、開発者のAPIへの信頼は高まり、APIの利用が増える可能性があります。[ 8 ]

用語の歴史

1978年の図では、APIの概念をアプリケーションプログラムだけでなく、汎用プログラミングインターフェースへと拡張することを提案している[ 9 ]

APIという用語は、当初、エンドユーザー向けプログラム（アプリケーションプログラム）向けのインターフェースのみを指していました。この由来は、現在でも「アプリケーション・プログラミング・インターフェース」という名称に反映されています。今日では、この用語はより広義に解釈され、ユーティリティソフトウェアやハードウェアインターフェースも含みます。[ 10 ]

APIという概念は、その用語自体よりもはるかに古い歴史を持つ。イギリスのコンピュータ科学者モーリス・ウィルクスとデイビッド・ウィーラーは、 1940年代に初期のコンピュータであるEDSAC向けにモジュール型ソフトウェアライブラリの開発に取り組んだ。このライブラリのサブルーチンは、ファイリングキャビネットに整理されたパンチ紙テープに格納されていた。このキャビネットには、ウィルクスとウィーラーが「ライブラリカタログ」と呼んだ、各サブルーチンに関するメモとプログラムへの組み込み方法をまとめた資料も含まれていた。今日では、このようなカタログはAPI（あるいはAPI仕様書、APIドキュメント）と呼ばれる。これは、プログラマが必要とする各サブルーチンの使い方（あるいは「呼び出し方」）を指示するものであるからである。[ 10 ]

ウィルクスとウィーラーの著書『電子デジタルコンピュータのためのプログラムの準備』には、初めて公開されたAPI仕様が掲載されている。ジョシュア・ブロックは、APIは発明されたというよりは発見された概念であるため、ウィルクスとウィーラーはAPIを「潜在的に発明した」と考えている。[ 10 ]

APIという用語を作り出した人々はUnivac 1108上でソフトウェアを実装していましたが、彼らのAPIの目的はハードウェアに依存しないプログラムを可能にすることでした。[ 11 ]

「アプリケーション・プログラム・インターフェース」（-ing接尾辞なし）という用語が初めて記録されたのは、1968年のAFIPS会議で発表された「リモート・コンピュータ・グラフィックスのためのデータ構造と技術」という論文である。 [ 12 ] [ 10 ]この論文の著者は、この用語をアプリケーション（この場合はグラフィックス・プログラム）とコンピュータ・システムの他の部分との相互作用を説明するために使用している。一貫性のあるアプリケーション・インターフェース（Fortranサブルーチン呼び出しで構成）は、プログラマがグラフィックス・ディスプレイ・デバイスの特異性に対処する手間を省き、コンピュータまたはディスプレイが交換された場合でもハードウェアの独立性を確保することを目的としていた。 [ 11 ]

この用語は、 CJ Date [ 13 ]が1974年に発表した論文「リレーショナル・アプローチとネットワーク・アプローチ：アプリケーション・プログラミング・インターフェースの比較」において、データベース分野に導入されました。[ 14 ] APIは、データベース管理システムのためのANSI/SPARCフレームワークの一部となりました。このフレームワークでは、アプリケーション・プログラミング・インターフェースは、クエリ・インターフェースなどの他のインターフェースとは別に扱われていました。1970年代のデータベース専門家は、これらの異なるインターフェースを組み合わせることができ、十分に豊富なアプリケーション・インターフェースは他のインターフェースもサポートできることに気づきました。[ 9 ]

この観察から、アプリケーションプログラミングだけでなく、あらゆる種類のプログラミングをサポートするAPIが生まれました。1990年までに、APIは技術者カール・マラマッドによって「プログラマが特定のタスクを実行するために利用できる一連のサービス」と定義されました。[ 15 ]

NASAが作成したWeb APIドキュメントのスクリーンショット

APIの概念は、リモート・プロシージャ・コール（RPC ）とWeb APIの登場とともに再び拡張されました。 1970年代から80年代にかけてコンピュータ・ネットワークが普及するにつれ、プログラマーはローカル・コンピュータだけでなく、他の場所にあるコンピュータ上のライブラリも呼び出すことを望むようになりました。こうしたRPCは、特にJava言語によって十分にサポートされていました。1990年代には、インターネットの普及に伴い、 CORBA、COM、DCOMなどの標準が、APIサービスを公開するための最も一般的な方法となるために競い合いました。[ 16 ]

ロイ・フィールディングは2000年にカリフォルニア大学アーバイン校で学位論文「アーキテクチャスタイルとネットワークベースのソフトウェアアーキテクチャの設計」を発表し、表現状態転送（REST）の概要を説明し、「ネットワークベースのアプリケーションプログラミングインターフェース」という概念を従来の「ライブラリベース」APIと対比させました。[ 17 ] XMLおよびJSON Web APIは2000年から商用利用が広がり、2021年現在も続いています。現在、Web APIはAPIという用語の最も一般的な意味となっています。[ 2 ]

2001年にティム・バーナーズ＝リーが提唱したセマンティックウェブには、「セマンティックAPI」が含まれていました。これは、APIをソフトウェアの動作インターフェースではなく、オープンで分散されたデータインターフェースとして再構築したものです。 [ 18 ]独自のインターフェースやエージェントがオープンなものよりも普及しましたが、データインターフェースとしてのAPIという概念が定着しました。ウェブAPIはあらゆる種類のデータをオンラインで交換するために広く使用されているため、APIはインターネット上の通信の多くを説明する広義の用語となっています。[ 16 ]このように使用される場合、APIという用語は通信プロトコルという用語と意味が重複します。

種類

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

ソフトウェアライブラリへのインターフェースはAPIの一種です。APIは「期待される動作」（仕様）を記述・規定しますが、ライブラリはこの一連のルールの「実際の実装」です

単一の API は、同じプログラミング インターフェイスを共有する異なるライブラリの形式で、複数の実装 (または抽象的であるため実装なし) を持つことができます。

APIと実装を分離することで、ある言語で書かれたプログラムから別の言語で書かれたライブラリを利用できるようになります。例えば、ScalaとJavaは互換性のあるバイトコードにコンパイルされるため、Scala開発者はあらゆるJava APIを活用できます。[ 19 ]

APIの利用方法は、使用するプログラミング言語の種類によって異なります。Luaのような手続き型言語のAPIは、主にコードの実行、データの操作、エラー処理などの基本ルーチンで構成されますが、Javaのようなオブジェクト指向言語のAPIは、クラスとそのクラスメソッドの仕様を提供します。[ 20 ] [ 21 ]ハイラムの法則は、「APIのユーザーが十分であれば、契約で何を約束したかは関係ありません。システムのすべての観測可能な動作は、誰かが依存していることになります。」と述べています。[ 22 ]一方、いくつかの研究によると、APIを使用するほとんどのアプリケーションは、APIの小さな部分を使用する傾向があります。 [ 23 ]

言語バインディングもAPIの一種です。ある言語の機能や性能を別の言語で実装されたインターフェースにマッピングすることで、ある言語で書かれたライブラリやサービスを別の言語で開発する際に利用できるようになります。[ 24 ] SWIGやF2PY （FortranからPythonへのインターフェースジェネレータ）などのツールは、このようなインターフェースの作成を容易にします。[ 25 ]

API はソフトウェア フレームワークと関連付けることもできます。フレームワークは複数の API を実装する複数のライブラリに基づくことができますが、API の通常の使用とは異なり、フレームワークに組み込まれた動作へのアクセスは、フレームワーク自体にプラグインされた新しいクラスを使用してそのコンテンツを拡張することによって仲介されます。

さらに、制御の反転や同様のメカニズムによって、プログラム全体の制御フローが呼び出し元の制御から外れ、フレームワークの制御下に置かれることもあります。 [ 26 ] [ 27 ]

オペレーティングシステム

APIは、アプリケーションとオペレーティングシステム間のインターフェースを指定できます。[ 28 ] 例えば、POSIXは、POSIX準拠のオペレーティングシステム用に作成されたアプリケーションを別のPOSIX準拠のオペレーティングシステム用に コンパイルできるようにすることを目的とした共通APIのセットを規定しています

LinuxとBerkeley Software DistributionはPOSIX APIを実装したオペレーティングシステムの例である。[ 29 ]

マイクロソフトは、特にWindows API (Win32) ライブラリ内で下位互換性のある API に強くこだわっており、古いアプリケーションは「互換モード」と呼ばれる実行ファイル固有の設定を使用して新しいバージョンの Windows でも実行できる可能性がある。[ 30 ]マイクロソフトの開発者が同社のオペレーティングシステムの内部 API にアクセスできることがどの程度有利であるかは不明である。1987年のテクノロジックコンピュータレターのリチャード A. シェイファーは、この状況を「マイクロソフトがすべてのバットとフィールドを所有している」野球の試合に例え、[ 31 ]ロータス デベロップメントやアシュトン テイトなどの大手ベンダーは、小規模なソフトウェア開発者には提供されていないMS-DOS 5.0に関する情報を受け取っていたと報じられている。[ 32 ]アシュトン テイトのエド エスバーは、1987 年のインタビューで、ビル ゲイツから、開発者は初期の API に基づいてソフトウェアを書き直さなければならないことがあると言われたと述べている。ゲイツ氏はインタビューの中で、マイクロソフトのApple MacintoshアプリケーションがMS-DOS用よりも成功したのは、同社がMac OSにもリソースを割く必要がなかったためだと指摘した。[ 33 ]

APIはアプリケーションバイナリインターフェース（ABI）とは異なり、APIはソースコードベースであるのに対し、ABIはバイナリベースです。例えば、POSIXはAPIを提供しますが、Linux Standard BaseはABIを提供します。[ 34 ] [ 35 ]

リモートAPI

リモートAPIを使用すると、開発者はプロトコル（言語やプラットフォームに関係なく、さまざまなテクノロジーを連携させるための特定の通信標準）を介してリモートリソースを操作できます。たとえば、Java Database Connectivity APIを使用すると、開発者は同じ関数セットを使用してさまざまな種類のデータベースにクエリを実行できます。一方、 Javaリモートメソッド呼び出しAPIは、Javaリモートメソッドプロトコルを使用して、リモートで操作されるが開発者にはローカルに見える関数の呼び出しを可能にします。 [ 36 ] [ 37 ]

したがって、リモート API は、オブジェクト指向プログラミングにおけるオブジェクトの抽象化を維持するのに役立ちます。プロキシオブジェクト上でローカルに実行されるメソッド呼び出しは、リモート プロトコルを使用してリモート オブジェクト上の対応するメソッドを呼び出し、戻り値としてローカルで使用される結果を取得します。

プロキシオブジェクトを変更すると、リモートオブジェクトもそれに応じて変更されます。[ 38 ]

Web API

Web APIは、企業とその資産を利用するアプリケーション間のやり取りを行うための定義済みのインターフェースであり、機能プロバイダーを指定し、APIユーザーにサービスパスまたはURLを公開するためのサービスレベルアグリーメント（SLA）でもあります。APIアプローチは、異なるタイプの消費者にサービスを提供する異なるアプリケーションに、一連のサービスへのプログラムインターフェースを提供することを中心としたアーキテクチャアプローチです。[ 39 ]

ウェブ開発の文脈で使用される場合、APIは通常、ハイパーテキスト転送プロトコル（HTTP）リクエストメッセージなどの仕様セットと、通常は拡張マークアップ言語（ XML）またはJavaScriptオブジェクト記法（JSON ）形式のレスポンスメッセージの構造定義として定義されます。例えば、eコマースに特化したウェブサイトに追加できる配送会社APIは、配送サービスの注文を容易にし、サイト開発者が配送会社の料金表をウェブデータベースに入力することなく、現在の配送料金を自動的に表示します。「ウェブAPI」は歴史的にウェブサービスとほぼ同義でしたが、最近のトレンド（いわゆるWeb 2.0 ）では、シンプルオブジェクトアクセスプロトコル（ SOAP）ベースのウェブサービスとサービス指向アーキテクチャ（SOA）から、より直接的な表現状態転送（REST）スタイルのウェブリソースとリソース指向アーキテクチャ（ROA）へと移行しています。[ 40 ]このトレンドの一部は、ウェブベースのオントロジーエンジニアリング技術を促進する概念であるリソース記述フレームワーク（RDF）へのセマンティックウェブの動向に関連しています。 Web APIは、複数のAPIを組み合わせてマッシュアップと呼ばれる新しいアプリケーションを作成することを可能にします。[ 41 ] ソーシャルメディア分野では、Web APIによってWebコミュニティがコミュニティ間やアプリケーション間でコンテンツやデータを共有することが容易になりました。これにより、ある場所で作成されたコンテンツを、Web上の複数の場所に動的に投稿および更新することが可能になります。[ 42 ]例えば、TwitterのREST APIは開発者がTwitterのコアデータにアクセスできるようにし、Search APIは開発者がTwitterの検索やトレンドデータとやり取りするための方法を提供します。[ 43 ]

デザイン

APIの設計はその使用に大きな影響を与えます。[ 5 ]情報隠蔽の原則は、プログラミングインターフェースの役割を、モジュールの実装の詳細を隠すことでモジュールプログラミングを可能にし、モジュールのユーザーがモジュール内の複雑さを理解する必要がないようにすることです。[ 44 ]したがって、APIの設計は、ユーザーが期待するツールのみを提供するように試みます。[ 5 ]プログラミングインターフェースの設計は、複雑なソフトウェアの構成であるソフトウェアアーキテクチャの重要な部分を表しています。 [ 45 ]

リリースポリシー

APIは、テクノロジー企業が統合を行う一般的な方法の1つです。APIを提供および使用する企業は、ビジネスエコシステムのメンバーとみなされます。[ 46 ]

APIを公開するための主なポリシーは次のとおりです。[ 47 ]

  • プライベート: API は社内使用のみを目的としています。
  • パートナー：APIは特定のビジネスパートナーのみが利用できます。例えば、UberやLyftなどの配車サービスは、承認されたサードパーティ開発者が自社のアプリ内から直接配車を依頼できるようにしています。これにより、企業はAPIにアクセスできるアプリを厳選することで品質管理を行い、新たな収益源を確保することができます。[ 48 ]
  • パブリック：APIは誰でも利用できます。例えば、MicrosoftはWindows APIを公開しており、Appleは自社のプラットフォーム向けにソフトウェアを開発できるようにAPI Cocoaをリリースしています。しかし、すべてのパブリックAPIが誰でもアクセスできるわけではありません。例えば、CloudflareやVoxilityなどのインターネットサービスプロバイダーは、RESTful APIを使用して、顧客や再販業者が自社のインフラストラクチャ情報、DDoS統計、ネットワークパフォーマンス、ダッシュボードコントロールにアクセスできるようにしています。[ 49 ]このようなAPIへのアクセスは、「APIトークン」または顧客ステータスの検証によって許可されます。[ 50 ]

パブリックAPIへの影響

APIが公開される際に重要な要素となるのは、「インターフェースの安定性」です。APIの変更（例えば、関数呼び出しに新しいパラメータを追加するなど）は、そのAPIに依存するクライアントとの互換性を損なう可能性があります。[ 51 ]

公開されているAPIの一部が変更の対象となり、安定していない場合は、そのAPIの該当部分を明示的に「不安定」と文書化する必要があります。例えば、Google Guavaライブラリでは、不安定とみなされ、近いうちに変更される可能性のある部分には、 Javaアノテーション が付けられています@Beta。[ 52 ]

公開APIは、その一部が非推奨または廃止されると宣言することがあります。これは通常、APIの一部が削除候補、または後方互換性のない形で変更される可能性があることを意味します。したがって、これらの変更により、開発者は将来削除またはサポートされなくなるAPIの一部から移行することができます。[ 53 ]

クライアントコードには、API設計者が意図していなかった革新的または便宜的な使用法が含まれている可能性があります。言い換えれば、大規模なユーザーベースを持つライブラリの場合、要素がパブリックAPIの一部になると、さまざまな方法で使用される可能性があります。[ 54 ] Akamaiは 2020年2月19日に年次レポート「インターネットの現状」を発表し、世界中の金融サービスのパブリックAPIプラットフォームを標的とするサイバー犯罪者の傾向が高まっていることを示しました。2017年12月から2019年11月までの間に、Akamaiは854.2億件の認証情報侵害攻撃を観測しました。約20％にあたる165.5億件は、APIエンドポイントとして定義されたホスト名に対するものでした。このうち4億7,350万件は金融サービス部門の組織を標的としていました。[ 55 ]

APIドキュメント

APIドキュメントは、APIが提供するサービスとそのサービスの使用方法を説明し、クライアントが実用上知っておく必要のあるすべての情報を網羅することを目的としています

ドキュメントは、APIを使用するアプリケーションの開発と保守に不可欠です。[ 56 ] APIドキュメントは、伝統的にドキュメントファイルに含まれていますが、ブログ、フォーラム、Q&Aウェブサイトなどのソーシャルメディアにも掲載されています。[ 57 ]

従来のドキュメントファイルは、JavadocやPydocといった、一貫した外観と構造を持つドキュメントシステムを介して提供されることが多い。しかし、ドキュメントに含まれるコンテンツの種類はAPIごとに異なる。[ 58 ]

明確さを重視するため、APIドキュメントには、API内のクラスとメソッドの説明、一般的な使用シナリオ、コードスニペット、設計上の根拠、パフォーマンスに関する議論、契約などが含まれる場合がありますが、APIサービス自体の実装の詳細は通常は省略されます。APIドキュメントは、説明文書、チュートリアル、参考資料など、さまざまな形式を取ります。また、ガイドや機能など、さまざまな種類の情報が含まれます。

APIの使用方法に関する制限事項もドキュメントに記載されています。例えば、API関数のドキュメントには、パラメータがnullであってはならないことや、関数自体がスレッドセーフではないことなどが明記されている場合があります。[ 59 ] APIドキュメントは網羅的になる傾向があるため、作成者にとってはドキュメントを最新の状態に保つことが難しく、ユーザーにとっては注意深く読むことが難しく、バグが発生する可能性もあります。[ 51 ]

APIドキュメントは、 Javaアノテーションなどのメタデータ情報で強化することができます。このメタデータは、コンパイラ、ツール、ランタイム環境でカスタム動作やカスタム処理を実装するために使用できます。[ 60 ]

データ駆動型でAPIドキュメントを生成することが可能です。特定のAPIを使用する多くのプログラムを観察することで、典型的な使用方法や必要な契約や指示を推測することが可能です。[ 61 ]そして、テンプレートを用いてマイニングされたデータから自然言語を生成することができます。

2010年、オラクル社は、Androidオペレーティングシステムに組み込まれたJavaの新しい実装を配布したとして、Google社を提訴した。[ 62 ] Google社は、類似のOpenJDKプロジェクトには許可を与えていたものの、Java APIの複製許可を取得していなかった。ウィリアム・アルサップ判事は、オラクル対Google訴訟において、APIは米国では著作権で保護できないと判決を下し、オラクル社が勝訴すれば著作権保護の範囲が「機能的な記号の集合」にまで拡大され、単純なソフトウェアコマンドの著作権保護も認められることになると述べた。

オラクルの主張を受け入れるということは、コマンドのシステムを実行するコードの一つのバージョンを誰でも著作権で保護できるようにし、それによって他のすべての人が同じコマンドの全部または一部を実行する異なるバージョンを書くことを禁止することになる。[ 63 ] [ 64 ]

アルサップの判決は2014年に連邦巡回控訴裁判所への控訴により覆されたが、このようなAPIの使用が公正使用に該当するかどうかという問題は未解決のままであった。[ 65 ] [ 66 ]

2016年、2週間の裁判の後、陪審はGoogleによるJava APIの再実装がフェアユースに該当すると判断したが、オラクルは控訴すると誓った。[ 67 ]オラクルは控訴で勝訴し、連邦巡回控訴裁判所はGoogleによるAPIの使用はフェアユースの要件を満たさないとの判決を下した。[ 68 ] 2019年、Googleは著作権とフェアユースの両方の判決をめぐって米国最高裁判所に控訴し、最高裁判所は審査を認めた。[ 69 ] COVID-19パンデミックのため、この事件の口頭審理は2020年10月まで延期された。[ 70 ]

この訴訟は最高裁判所によってグーグルの勝訴で判決された。[ 71 ]

例

参照

参考資料

  1. ^ a b Reddy, Martin (2011). C++ API Design for C++ . Elsevier Science. p. 1. ISBN 9780123850041。
  2. ^ a b Lane, Kin (2019年10月10日). 「API入門：APIの歴史」 . Postman . 2020年9月18日閲覧. 「API」またはその拡張版である「アプリケーション・プログラミング・インターフェース」という略語を耳にすると、ほとんどの場合、HTTPを使用してJSONまたはXML形式の機械可読データへのアクセスを提供するという現代的なアプローチを指しており、多くの場合、単に「Web API」と呼ばれます。APIはコンピューティングとほぼ同じくらい長い間存在してきましたが、現代のWeb APIは2000年代初頭に形を整え始めました。
  3. ^ a b Pedro, Bruno (2024). API製品の構築：ユーザーニーズを満たすAPI製品の設計、実装、リリース、保守. Packt Publishing. p. 4. ISBN 9781837638536。
  4. ^ Biehl, Matthias (2016). RESTful API Design . API-University Press. p. 10. ISBN 9781514735169。
  5. ^ a b cクラーク、スティーブン (2004). 「APIユーザビリティの測定」 .ドクター・ドブズ. 2016年7月29日閲覧
  6. ^ジン、ブレンダ、サーニ、サウラブ、シェヴァット、アミール (2018). 「序文」. Web APIの設計：開発者が愛するAPIの構築. O'Reilly Media. ISBN 9781492026877。
  7. ^ Geewax, JJ (2021). APIデザインパターン. Manning. p. 6. ISBN 9781638350330。
  8. ^ジェイコブソン、ダニエル、ブレイル、ダン（2011年）。API ：戦略ガイド。オライリーメディア。4ページ。ISBN 9781449321642。
  9. ^ a bデータベースアーキテクチャ - 実現可能性ワークショップ（報告書）。ワシントンD.C.：米国商務省、国立標準局。1981年4月。pp.  45– 47。hdl : 2027 / mdp.39015077587742。LCCN 81600004。NBS特別出版物500-76 。 2020年9月18日閲覧 
  10. ^ a b c dブロッホ、ジョシュア(2018 年 8 月 8 日)。API に関する簡潔かつ独自の歴史(スピーチ)。 Qコン。サンフランシスコ: InfoQ 。2020 年9 月 18 日に取得。
  11. ^ a b Cotton, Ira W.; Greatorex, Frank S. (1968年12月). 「リモートコンピュータグラフィックスのためのデータ構造と技術」 . AFIPS '68: 1968年12月9～11日開催の秋季合同コンピュータ会議議事録. AFIPS 1968 Fall Joint Computer Conference. 第1巻. カリフォルニア州サンフランシスコ: Association for Computing Machinery. pp.  533– 544. doi : 10.1145/1476589.1476661 . ISBN 978-1450378994 OCLC  1175621908
  12. ^ 「アプリケーション・プログラム・インターフェース」オックスフォード英語辞典（オンライン版）オックスフォード大学出版局(サブスクリプションまたは参加機関のメンバーシップが必要です。)
  13. ^ Date, CJ (2019). EF Coddとリレーショナル理論：Coddの主要なデータベース著作の詳細なレビューと分析. Lulu.com. p. 135. ISBN 978-1684705276。
  14. ^ Date, CJ; Codd, EF (1975年1月). 「リレーショナルアプローチとネットワークアプローチ：アプリケーションプログラミングインターフェースの比較」 . Randall Rustin (編). 1974 ACM-SIGMOD Workshop on Data Description, Access and Control Proceedings of 1974 ACM-SIGMOD Workshop on Data Description, Access and Control . SIGMOD Workshop 1974. Vol. 2. ミシガン州アナーバー：Association for Computing Machinery. pp.  83– 113. doi : 10.1145/800297.811532 . ISBN 978-1450374187 OCLC  1175623233
  15. ^カール、マラマッド(1990). Novellネットワークの分析. ヴァン・ノストランド・ラインホールド. 294ページ. ISBN 978-0442003647。
  16. ^ a bジン、ブレンダ、サーニ、サウラブ、シェヴァット、アミール (2018). Web APIの設計. オライリーメディア. ISBN 9781492026877。
  17. ^ Fielding, Roy (2000).アーキテクチャスタイルとネットワークベースソフトウェアアーキテクチャの設計(PhD) . 2020年9月18日閲覧
  18. ^ Dotsika, Fefie (2010年8月). 「セマンティックAPI：セマンティックウェブに向けたスケールアップ」. International Journal of Information Management . 30 (4): 335– 342. doi : 10.1016/j.ijinfomgt.2009.12.003 .
  19. ^ Odersky, Martin; Spoon, Lex; Venners, Bill (2008年12月10日). 「ScalaとJavaの組み合わせ」 . www.artima.com . 2016年7月29日閲覧。
  20. ^ de Figueiredo, Luiz Henrique; Ierusalimschy, Roberto ; Filho, Waldemar Celes (1994). 「アプリケーションを拡張するための言語の設計と実装」 . Proceedings of XXI Brazilian Seminar on Software and Hardware . pp.  273– 284. CiteSeerX 10.1.1.47.5194 . S2CID 59833827. 2016年7月29日閲覧.  
  21. ^ Sintes, Tony (2001年7月13日). 「Java APIとは一体何なのか？」 . JavaWorld . 2020年7月18日閲覧。
  22. ^ウィンターズ、タイタス​​、トム・マンシュレック、ハイラム・ライト編 (2020). 『Googleにおけるソフトウェアエンジニアリング：長年にわたるプログラミングから学んだ教訓』セバストポル、カリフォルニア州: オライリーメディア. ISBN 9781492082798 OCLC  1144086840
  23. ^ Mastrangelo, Luis ; Ponzanelli, Luca; Mocci, Andrea; Lanza, Michele; Hauswirth, Matthias; Nystrom, Nathaniel (2015-10-23). 「自己責任で使用してください：Javaの安全でないAPIの現状」. 2015 ACM SIGPLAN 国際オブジェクト指向プログラミング、システム、言語、およびアプリケーション会議議事録. ニューヨーク州ニューヨーク：米国計算機協会. pp.  695– 710. doi : 10.1145/2814270.2814313 . ISBN 978-1-4503-3689-5。
  24. ^エメリー、デイビッド。「標準、API、インターフェース、バインディング」。Acm.org。2015年1月16日時点のオリジナルからのアーカイブ。2016年8月8日閲覧
  25. ^ "F2PY.org" . F2PY.org . 2011年12月18日閲覧。
  26. ^ファウラー、マーティン、「制御の反転」。
  27. ^ Fayad, Mohamed. 「オブジェクト指向アプリケーションフレームワーク」
  28. ^ドナルド・A. ルワイン著 (1991). POSIXプログラマーズ・ガイド. O'Reilly & Associates, Inc. p. 1. ISBN 97809371757362016年8月2日閲覧
  29. ^ West, Joel; Dedrick, Jason (2001). 「オープンソース標準化：ネットワーク時代におけるLinuxの台頭」（PDF） . Knowledge, Technology & Policy . 14 (2): 88– 112. doi : 10.1007/PL00022278 . 2016年8月2日閲覧。
  30. ^ Microsoft (2001年10月). 「Windows XPのサポート」 . Microsoft. p. 4. 2009年9月26日時点のオリジナルよりアーカイブ。
  31. ^バーニー・ダグラス (1987年11月2日). 「マイクロソフトの成功を左右する綱渡り」 . Computerworld . 第21巻第44号. p. SR15 . 2025年6月8日閲覧。
  32. ^バーニー・ダグラス (1986年7月7日). 「えこひいきと中小企業」 .コンピュータワールド. 第20巻第27号. 45, 50ページ. 2026年1月13日閲覧。
  33. ^ビル・ゲイツ、ジム・マンジ、エド・エスバー (1987年11月2日). 「ソフトウェアをめぐる大論争」 . Computerworld (インタビュー). Vol. XXI, no. 44. ポール・ギリンによるインタビュー. p. SR7. 2025年6月8日閲覧。
  34. ^ 「LSB Introduction」 . Linux Foundation. 2012年6月21日. 2015年4月2日時点のオリジナルよりアーカイブ。 2015年3月27日閲覧。
  35. ^ Stoughton, Nick (2005年4月). 「Update on Standards」(PDF) . USENIX . 2009年6月4日閲覧。
  36. ^ Bierhoff, Kevin (2009年4月23日). 「オブジェクト指向ソフトウェアにおけるAPIプロトコル準拠」(PDF) . CMUソフトウェア研究所. 2016年7月29日閲覧。
  37. ^ Wilson, M. Jeff (2000年11月10日). 「プロキシとRMIで賢く使おう」 . JavaWorld . 2020年7月18日閲覧。
  38. ^ヘニング、ミチ、ヴィノスキー、スティーブ (1999). 『C++によるCORBAプログラミング入門』 . Addison-Wesley . ISBN 978-02013792732015年6月16日閲覧
  39. ^ 「API化」(PDF) . www.hcltech.com . 2014年8月.
  40. ^ Benslimane, Djamal; Schahram Dustdar; Amit Sheth (2008). 「サービスマッシュアップ：新世代のWebアプリケーション」 . IEEE Internet Computing . 12 (5). IEEE: 13– 15. Bibcode : 2008IIC....12e..13B . doi : 10.1109/MIC.2008.110 . 2019年10月1日閲覧。
  41. ^ Niccolai, James (2008-04-23)、「So What Is an Enterprise Mashup, Anyway?」、PC World 、 2017年10月10日時点のオリジナルよりアーカイブ、 2017年9月17日閲覧。
  42. ^ Parr, Ben (2009年5月21日). 「ソーシャルメディアAPIの進化」 . Mashable . 2016年7月26日閲覧。
  43. ^ 「GET trends/place」 . developer.twitter.com . 2020年4月30日閲覧。
  44. ^ Parnas, DL (1972). 「システムをモジュールに分解する際に使用する基準について」(PDF) . Communications of the ACM . 15 (12): 1053– 1058. doi : 10.1145/361598.361623 . S2CID 53856438 . 
  45. ^ Garlan, David; Shaw, Mary (1994年1月). 「ソフトウェアアーキテクチャ入門」(PDF) . 『ソフトウェア工学と知識工学の進歩』 . 1. 2016年8月8日閲覧.
  46. ^ de Ternay, Guerric (2015年10月10日). 「ビジネス・エコシステム：経済的堀の創出」 . BoostCompanies . 2016年9月17日時点のオリジナルよりアーカイブ。 2016年2月1日閲覧。
  47. ^ Boyd, Mark (2014年2月21日). 「プライベート、パートナー、パブリック：ビジネスに最適なAPI戦略はどれか？」 ProgrammableWeb . 2016年8月2日閲覧。
  48. ^ Weissbrot, Alison (2016年7月7日). 「カーサービスAPIはどこにでもあるが、パートナーアプリにとってのメリットは何か？」AdExchanger .
  49. ^ 「Cloudflare API v4ドキュメント」 . cloudflare . 2020年2月25日. 2020年2月27日閲覧。
  50. ^ Liew, Zell (2018年1月17日). 「カーサービスAPIはどこにでもあるが、パートナーアプリにとって何のメリットがあるのだろうか」 . Smashing Magazine . 2020年2月27日閲覧。
  51. ^ a b Shi, Lin; Zhong, Hao; Xie, Tao; Li, Mingshu (2011). APIドキュメントの進化に関する実証的研究. ソフトウェア工学への基本的アプローチに関する国際会議. コンピュータサイエンス講義ノート. 第6603巻. pp.  416– 431. doi : 10.1007/978-3-642-19811-3_29 . ISBN 978-3-642-19810-6. 2016年7月22日閲覧。
  52. ^ google/guava: GitHub上のJava 用 Google Core ライブラリ
  53. ^ Oracle. 「APIを廃止する方法と時期」 . Java SEドキュメント. 2016年8月2日閲覧。
  54. ^ Mendez, Diego; Baudry, Benoit; Monperrus, Martin (2013).オブジェクト指向ソフトウェアにおけるAPI利用における大規模な多様性に関する実証的証拠. 2013 IEEE 第13回国際ソースコード分析・操作ワーキングカンファレンス (SCAM). pp.  43– 52. arXiv : 1307.4062 . doi : 10.1109/SCAM.2013.6648183 . ISBN 978-1-4673-5739-5. S2CID  6890739.
  55. ^ディーン・タカナシ（2020年2月19日） 「Akamai：サイバー犯罪者が金融サービス企業のAPIを攻撃」 Venture Beat . 2020年2月27日閲覧
  56. ^ Dekel, Uri; Herbsleb, James D. (2009年5月). 「ナレッジプッシュによるAPIドキュメントのユーザビリティ向上」. Institute for Software Research, School of Computer Science . CiteSeerX 10.1.1.446.4214 . 
  57. ^ Parnin, Chris; Treude, Cristoph (2011年5月). 「Web上のAPIドキュメントの測定」 .第2回ソフトウェアエンジニアリングのためのWeb 2.0に関する国際ワークショップ議事録. pp.  25– 30. doi : 10.1145/1984701.1984706 . ISBN 9781450305952. S2CID  17751901 . 2016年7月22日閲覧
  58. ^ Maalej, Waleed; Robillard, Martin P. (2012年9月). 「APIリファレンスドキュメントにおける知識パターン」(PDF) . IEEE Transactions on Software Engineering . 39 (9): 1264– 1282. doi : 10.1109/TSE.2013.12 . 2016年7月22日閲覧.
  59. ^ Monperrus, Martin; Eichberg, Michael; Tekes, Elif; Mezini, Mira (2011年12月3日). 「開発者は何に注意すべきか？ APIドキュメントの指示に関する実証的研究」. Empirical Software Engineering . 17 (6): 703– 737. arXiv : 1205.6363 . doi : 10.1007/s10664-011-9186-4 . S2CID 8174618 . 
  60. ^ 「注釈」 . Sun Microsystems . 2011年9月25日時点のオリジナルよりアーカイブ。2011年9月30日閲覧。。
  61. ^ Bruch, Marcel; Mezini, Mira; Monperrus, Martin (2010).フレームワークの再利用性を向上させるためのサブクラス化ディレクティブのマイニング．2010年第7回IEEEソフトウェアリポジトリマイニングワーキングカンファレンス (MSR 2010). pp.  141– 150. CiteSeerX 10.1.1.434.15 . doi : 10.1109/msr.2010.5463347 . ISBN  978-1-4244-6802-7. S2CID  1026918 .
  62. ^ 「Oracleと私たちが知っているプログラミングの終焉」 DrDobbs. 2012年5月1日. 2012年5月9日閲覧
  63. ^ 「Oracle訴訟の判事、APIは著作権で保護されないと主張」 TGDaily. 2012年6月1日. 2020年7月31日時点のオリジナルよりアーカイブ。 2012年12月6日閲覧。
  64. ^ 「Oracle America, Inc. vs. Google Inc」（PDF） . Wired . 2012年5月31日. 2013年9月22日閲覧。
  65. ^ 「Oracle Am., Inc. v. Google Inc., No. 13-1021, Fed. Cir. 2014」 Justia Law。
  66. ^ Rosenblatt, Seth (2014年5月9日). 「Java特許控訴で、裁判所はAndroidを巡るOracleの主張を支持」 . CNET . 2014年5月10日閲覧。
  67. ^ 「GoogleがOracleに勝利 - AndroidはJava APIを「公正に利用」」 Ars Technica 2016年5月26日2016年7月28日閲覧。
  68. ^ Decker, Susan (2018年3月27日). 「Oracle、Googleに対する10億ドル規模の訴訟の復活に勝利」 . Bloomberg Businessweek . 2018年3月27日閲覧。
  69. ^ Lee, Timothy (2019年1月25日). 「Google、API著作権に関する破滅的な判決を覆すよう最高裁に要請」 Ars Technica . 2019年2月8日閲覧。
  70. ^ vkimber (2020年9月28日). 「Google LLC v. Oracle America, Inc.」 LII / Legal Information Institute . 2021年3月6日閲覧。
  71. ^ 「米国最高裁判所、No. 18–956、GOOGLE LLC、請願者対ORACLE AMERICA、INC」（PDF）。2021年4月5日。

さらに読む

  • タイナ・ブッチャー（2013年11月16日）. 「強烈な感情の対象：Twitter APIの事例」 .計算文化(3). ISSN  2047-2390 .「API は中立的なツールからは程遠い」ものであり、文化の基本的な部分として理解される現代のプログラミングの重要な部分を形成していると主張します。
  • APIとは何か？ – 米国最高裁判所の判決、Google v. Oracle 2021、3～7ページ – 「各タスクにはコンピュータコードがあります。API（アプリケーション・プログラム・インターフェースとも呼ばれます）は、その「コンピュータコード」（料理の指示ではなく、レシピのような指示、つまり機械語の指示）を呼び出して実行するための方法です。」
  • モーリー、イノベーションと変革– コリー・オンドレイカ \ 2014年2月28日 \ 「…コンピューター同士が通信できるようにする公開APIを提案した」。（Textise URL）
「 https://en.wikipedia.org/w/index.php?title=API&oldid=1332785353」より取得