API

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

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

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

APIの目的の1つは、システムの動作の内部の詳細を非表示にし、プログラマーが役立つと思われる部分のみを公開し、内部の詳細が後で変更された場合でも一貫性を保つことです。APIは、特定のシステムペア用にカスタムビルドすることも、多くのシステム間の 相互運用性を可能にする共有標準にすることもできます。

APIという用語は、インターネットで接続されているコンピューター間の通信を可能にするWebAPI [ 2]を指すためによく使用されますプログラミング言語ソフトウェアライブラリ、コンピュータオペレーティングシステム、およびコンピュータハードウェア用のAPIもありますAPIは1940年代に始まりましたが、この用語は1960年代と1970年代まで登場しませんでした。

目的

アプリケーションの構築では、API(アプリケーションプログラミングインターフェイス)は、基盤となる実装を抽象化し、開発者が必要とするオブジェクトまたはアクションのみを公開することにより、プログラミングを簡素化します。電子メールクライアントのグラフィカルインターフェイスは、新しい電子メールをフェッチして強調表示するためのすべての手順を実行するボタンをユーザーに提供する場合がありますが、ファイル入出力用のAPIは、開発者に、ファイルをある場所から別の場所にコピーする機能を提供する場合があります。開発者が舞台裏で行われるファイルシステム操作を理解することを要求します。[3]

用語の歴史

アプリケーションプログラムだけでなく、一般的なプログラミングインターフェイスになるためのAPIのアイデアの拡張を提案する1978年の図。[4]

APIという用語は、当初、アプリケーションプログラムと呼ばれるエンドユーザー向けプログラム専用のインターフェイスを表していますこの起源は、「アプリケーションプログラミングインターフェイス」という名前に今でも反映されています。今日では、この用語はより広く、ユーティリティソフトウェアハードウェアインターフェイスも含まれています。[5]

1940年代と1950年代

APIの概念は、用語自体よりもはるかに古いものです。イギリスのコンピューター科学者であるモーリスウィルクスデビッドホイーラーは、1940年代に、初期のコンピューターであるEDSAC用のモジュラーソフトウェアライブラリに取り組みました。このライブラリのサブルーチンは、ファイリングキャビネットに整理された紙テープに保存さましこのキャビネットには、WilkesとWheelerが各サブルーチンに関するメモの「ライブラリカタログ」と呼んだものと、それをプログラムに組み込む方法も含まれていました。今日、このようなカタログは、プログラマーが必要とする各サブルーチンの使用方法(または「呼び出し」)をプログラマーに指示するため、API(またはAPI仕様またはAPIドキュメント)と呼ばれます。[5]

Wilkes andWheelerの1951年の著書ThePreparation of Programs for a Electronic Digital Computerには、最初に公開されたAPI仕様が含まれています。Joshua Blochは、WilkesとWheelerがAPIを「潜在的に発明した」と考えています。これは、APIが発明されたというよりも、発見された概念であるためです。[5]

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

1960年代と1970年代

「アプリケーションプログラムインターフェイス」(-ingサフィックスなし)という用語は、1968年のAFIPS会議で発表されたリモートコンピュータグラフィックスのデータ構造と技術と呼ばれる論文に最初に記録されました。 [7] [5]この論文の著者はアプリケーション(この場合はグラフィックプログラム)とコンピュータシステムの他の部分との相互作用を表す用語。一貫性のあるアプリケーションインターフェイス( Fortranサブルーチン呼び出しで構成される)は、プログラマーがグラフィックスディスプレイデバイスの特異性に対処することから解放し、コンピューターまたはディスプレイが交換された場合にハードウェアに依存しないようにすることを目的としていました。[6]

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

この観察により、アプリケーションプログラミングだけでなく、すべてのタイプのプログラミングをサポートするAPIが生まれました。

1990年代

1990年までに、APIは、技術者のCarl Malamudによって、単に「プログラマーが特定のタスクを実行するために利用できる一連のサービス」として定義されていました[10]

APIのアイデアは、リモートプロシージャコールWebAPIの夜明けとともに再び拡張されました1970年代と1980年代にコンピューターネットワークが一般的になるにつれ、プログラマーはローカルコンピューターだけでなく、他の場所にあるコンピューターにあるライブラリーに電話をかけたいと考えました。これらのリモートプロシージャコールは、特にJava言語で十分にサポートされていました。1990年代、インターネットの普及に伴い、 CORBACOMDCOMなどの標準が、APIサービスを公開するための最も一般的な方法になるために競争しました。[11]

2000年代

RoyFieldingの論文ArchitecturalStyles and the Design of Network-based Software Architectures at UC Irvine in 2000は、Representational State Transfer(REST)の概要を説明し、Fieldingが従来の「ライブラリ-ベースの」API。[12] XMLおよびJSONWeb APIは、2000年に始まり、2021年まで継続して広く商業的に採用されました。現在、WebAPIはAPIという用語の最も一般的な意味です。[2]

2001年にTimBerners-Leeによって提案されたセマンティックWebには、APIをソフトウェア動作インターフェイスではなくオープンな分散データインターフェイスとして再キャストする「セマンティックAPI」が含まれていました。[13]独自のインターフェースとエージェントは、オープンなものよりも普及しましたが、データインターフェースとしてのAPIのアイデアは定着しました。Web APIは、あらゆる種類のデータをオンラインで交換するために広く使用されているため、APIは、インターネット上の通信の多くを表す広義の用語になりました。[11]このように使用される場合、APIという用語は、通信プロトコルという用語と意味が重複しています。

使用法

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

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

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

APIをその実装から分離することにより、ある言語で記述されたプログラムが別の言語で記述されたライブラリを使用できるようになります。たとえば、ScalaJavaは互換性のあるバイトコードにコンパイルされるため、Scala開発者は任意のJavaAPIを利用できます。[14]

APIの使用は、関連するプログラミング言語のタイプによって異なります。Luaなどの手続き型言語のAPIは、主にコードの実行、データの操作、エラーの処理を行う基本的なルーチンで構成できますが、Javaなどのオブジェクト指向言語のAPIは、クラスとそのクラスメソッドの仕様を提供します。[15] [16] Hyrumの法則[17]は、「APIのユーザー数が十分であれば、契約で何を約束するかは重要ではありません。システムのすべての観察可能な動作は、誰かに依存されます」と述べています。一方、いくつかの調査によると、APIを使用するほとんどのアプリケーションはAPIのごく一部を使用する傾向があります。[18] APIの使用は、実際にはユーザーの数とAPIの人気によって異なります。[19]

言語バインディングもAPIです。ある言語の機能を別の言語で実装されたインターフェイスにマッピングすることにより、言語バインディングにより、ある言語で記述されたライブラリまたはサービスを別の言語で開発するときに使用できます。[20]

SWIGやF2PY FortranからPythonへのインターフェースジェネレーターなどのツールは、そのようなインターフェースの作成を容易にします。[21]

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

さらに、制御の全体的なプログラムフローは、制御の反転または同様のメカニズムによって、呼び出し元の制御から外れ、フレームワークの手に渡る可能性があります。[22] [23]

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

APIは、アプリケーションとオペレーティングシステム間のインターフェイスを指定できます。[24] たとえば、POSIXは、POSIX準拠のオペレーティングシステム用に作成されたアプリケーションを別のPOSIX準拠のオペレーティングシステム用にコンパイルできるようにすることを目的とした一連の一般的なAPIを指定します。

LinuxBerkeleySoftware Distributionは、POSIXAPIを実装するオペレーティングシステムの例です。[25]

Microsoftは、特にWindows API (Win32)ライブラリ内で下位互換性のあるAPIに強いコミットメントを示しているため、「互換モード」と呼ばれる実行可能ファイル固有の設定を使用して、古いアプリケーションを新しいバージョンのWindowsで実行できます。[26]

APIは、APIがソースコードベースであるのに対し、ABIはバイナリベースであるという点で、アプリケーションバイナリインターフェイス(ABI)とは異なります。たとえば、POSIXはAPIを提供し、Linux StandardBaseはABIを提供します。[27] [28]

リモートAPI

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

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

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

Web API

Web APIは、企業とその資産を使用するアプリケーションとの間で相互作用が発生する定義済みのインターフェイスです。これは、機能プロバイダーを指定し、APIユーザーのサービスパスまたはURLを公開するためのサービスレベルアグリーメント(SLA)でもあります。APIアプローチは、さまざまなタイプのコンシューマーにサービスを提供するさまざまなアプリケーションに一連のサービスへのプログラムインターフェイスを提供することを中心に展開するアーキテクチャアプローチです。[32]

Web開発のコンテキストで使用される場合、APIは通常、ハイパーテキスト転送プロトコル(HTTP)要求メッセージなどの仕様のセットとして定義され、応答メッセージの構造の定義とともに、通常はExtensible Markup Language(XML )で定義されます。 )またはJavaScript Object Notation(JSON)形式。例としては、eコマースに焦点を当てたWebサイトに追加して、サイト開発者がWebデータベースに配送業者の料金表を入力しなくても、配送サービスの注文を容易にし、現在の配送料金を自動的に含めることができる配送会社APIがあります。「WebAPI」は歴史的にWebサービスと実質的に同義でしたが、最近の傾向(いわゆるWeb 2.0 ))は、Simple Object Access Protocol(SOAP)ベースのWebサービスおよびサービス指向アーキテクチャー(SOA)から、より直接的なRepresentational State Transfer(REST)スタイルのWebリソースおよびリソース指向アーキテクチャー(ROA)に移行しています。[33]この傾向の一部は、Webベースのオントロジーエンジニアリング技術を促進するための概念であるResource Description Framework (RDF)へのセマンティックWebの動きに関連しています。Web APIを使用すると、複数のAPIを組み合わせてマッシュアップと呼ばれる新しいアプリケーションにすることができます。[34] ソーシャルメディアの分野では、Web APIにより、Webコミュニティはコミュニティとアプリケーション間でコンテンツとデータを共有しやすくなっています。このようにして、1つの場所で動的に作成されたコンテンツを、Web上の複数の場所に投稿および更新できます。[35]たとえば、TwitterのREST APIを使用すると、開発者はコアTwitterデータにアクセスでき、Search APIは、開発者がTwitter検索およびトレンドデータを操作するためのメソッドを提供します。[36]

デザイン

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

リリースポリシー

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

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

  • プライベート:APIは社内でのみ使用されます。
  • パートナー:特定のビジネスパートナーのみがAPIを使用できます。たとえば、UberLyftなどのハイヤー会社では、承認されたサードパーティのデベロッパーがアプリ内から直接乗り物を注文できます。これにより、企業はAPIにアクセスできるアプリをキュレートすることで品質管理を実行でき、追加の収益源を提供します。[41]
  • パブリック:APIはパブリックで使用できます。たとえば、MicrosoftWindows APIを公開し、AppleはそのAPI Cocoaをリリースして、ソフトウェアをプラットフォーム用に作成できるようにします一般に、すべてのパブリックAPIに誰もがアクセスできるわけではありません。たとえば、CloudflareやVoxilityなどのインターネットサービスプロバイダーは、RESTful APIを使用して、顧客や再販業者がインフラストラクチャ情報、DDoS統計、ネットワークパフォーマンス、ダッシュボードコントロールにアクセスできるようにします。[42]このようなAPIへのアクセスは、「APIトークン」または顧客ステータスの検証のいずれかによって許可されます。[43]

パブリックAPIの意味

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

公開されているAPIの一部が変更される可能性があり、したがって安定していない場合、特定のAPIのそのような部分は「不安定」として明示的に文書化する必要があります。たとえば、Google Guavaライブラリでは、不安定であると見なされ、間もなく変更される可能性のある部分にJavaアノテーション @Betaが付けられます。[45]

パブリックAPIは、それ自体の一部を非推奨または取り消されたものとして宣言する場合があります。これは通常、APIの一部を削除するか、下位互換性のない方法で変更する候補と見なす必要があることを意味します。したがって、これらの変更により、開発者は、削除されるか、将来サポートされなくなるAPIの部分から移行することができます。[46]

クライアントコードには、API設計者が意図していなかった革新的または日和見的な使用法が含まれている場合があります。言い換えれば、重要なユーザーベースを持つライブラリの場合、要素がパブリックAPIの一部になると、さまざまな方法で使用される可能性があります。[47] 2020年2月19日、アカマイは毎年恒例の「インターネットの状態」レポートを公開し、世界中の金融サービスでパブリックAPIプラットフォームを標的とするサイバー犯罪者の増加傾向を示しました。2017年12月から2019年11月まで、アカマイは854.2億件の資格侵害攻撃を目撃しました。約20%、つまり165.5億は、APIエンドポイントとして定義されたホスト名に反対していました。これらのうち、4億7,350万人が金融サービス部門の組織を標的にしています。[48]

ドキュメント

APIドキュメントでは、APIが提供するサービスとそれらのサービスの使用方法について説明し、クライアントが実際の目的で知る必要のあるすべてを網羅することを目的としています。

APIを使用したアプリケーションの開発と保守には、ドキュメントが不可欠です。[49] APIドキュメントは、従来、ドキュメントファイルに含まれていましたが、ブログ、フォーラム、Q&AWebサイトなどのソーシャルメディアにも含まれています。[50]

従来のドキュメントファイルは、多くの場合、一貫した外観と構造を持つJavadocやPydocなどのドキュメントシステムを介して表示されます。ただし、ドキュメントに含まれるコンテンツの種類はAPIごとに異なります。[51]

わかりやすくするために、APIドキュメントには、APIのクラスとメソッドの説明、および「一般的な使用シナリオ、コードスニペット、設計の根拠、パフォーマンスの説明、契約」が含まれる場合がありますが、APIサービス自体の実装の詳細は通常省略。

APIの使用方法に関する制限と制限についても、ドキュメントで説明されています。たとえば、API関数のドキュメントでは、そのパラメータをnullにすることはできず、関数自体はスレッドセーフではないことに注意することができます。[52] APIドキュメントは包括的である傾向があるため、ライターがドキュメントを最新の状態に保ち、ユーザーがそれを注意深く読むことは課題であり、バグが発生する可能性があります。[44]

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

データ駆動型の方法でAPIドキュメントを生成することが可能です。特定のAPIを使用する多くのプログラムを観察することにより、一般的な使用法、および必要なコントラクトとディレクティブを推測することができます。[54]次に、テンプレートを使用して、マイニングされたデータから自然言語を生成できます。

APIの著作権保護をめぐる論争

2010年、Oracle Corporationは、Androidオペレーティングシステムに組み込まれたJavaの新しい実装を配布したとしてGoogleを訴えました。[55]同様のOpenJDKプロジェクトに許可が与えられていたにもかかわらず、GoogleはJavaAPIを複製する許可を取得していませんでした。ウィリアム・アルサップ裁判官は、オラクル対グーグルの訴訟で、APIは米国では著作権で保護されておらずオラクルの勝利は著作権保護を「機能的なシンボルのセット」に広く拡大し、単純なソフトウェアコマンドの著作権を許可するだろうと 裁定しました。

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

アルサップの判決は、連邦巡回控訴裁判所への控訴で2014年に覆されましたが、APIのそのような使用がフェアユースを構成するかどうかの問題は未解決のままでした。[58] [59]

2016年、2週間の裁判の後、陪審員はGoogleによるJava APIの再実装がフェアユースであると判断しましたが、Oracleはその決定に上訴することを誓いました。[60]オラクルは、GoogleによるAPIの使用はフェアユースの資格がないとの連邦巡回控訴裁判所の判決を下し、上訴で勝訴しました。[61] 2019年、Googleは、著作権とフェアユースの判決の両方について合衆国最高裁判所に控訴し、最高裁判所は審査を認めました。[62] COVID-19のパンデミックにより、この事件の口頭審理は2020年10月まで延期された。[63]

この訴訟は、Googleに有利な最高裁判所によって決定されました。[64]

も参照してください

参考文献

  1. ^ レディ、マラーティー語(2011)。C ++用のAPIデザインエルゼビアサイエンス。p。1.ISBN _ 9780123850041
  2. ^ a b レーン、キン(2019年10月10日)。「APIの概要:APIの歴史」郵便配達員2020年9月18日取得頭字語「API」またはその拡張バージョン「アプリケーションプログラミングインターフェイス」を聞くとき、それはほとんどの場合、HTTPを使用してJSONまたはXML形式の機械可読データへのアクセスを提供するという点で最新のアプローチを参照しています。 「WebAPI」と呼ばれます。APIはコンピューティングとほぼ同じくらい長い間存在していましたが、最新のWebAPIは2000年代初頭に形になり始めました。
  3. ^ a b c クラーク、スティーブン(2004)。「APIユーザビリティの測定」ドブ博士の2016年7月29日取得
  4. ^ a b データベースアーキテクチャ–実現可能性ワークショップ(レポート)。ワシントンDC:米国商務省、国立標準局。1981年4月。45〜47ページ。hdl2027 /mdp.39015077587742LCCN81600004_ NBS特別刊行物500-76 2020年9月18日取得 
  5. ^ a b c d Bloch、Joshua(2018年8月8日)。API (スピーチ)の簡単な意見の歴史。QCon。サンフランシスコ:InfoQ 2020年9月18日取得
  6. ^ a b コットン、イラW。; Greatorex、Frank S.(1968年12月)。「リモートコンピュータグラフィックスのデータ構造と技術」AFIPS '68:1968年12月9〜11日の議事録、秋の合同コンピュータ会議AFIPS1968秋合同コンピュータ会議。I.サンフランシスコ、カリフォルニア:Association for ComputingMachinery。pp。533–544。土井10.1145 /1476589.1476661ISBN 978-1450378994OCLC1175621908 _
  7. ^ 「アプリケーションプログラムインターフェース」オックスフォード英語辞典(オンライン版)。オックスフォード大学出版局 (サブスクリプションまたは参加機関のメンバーシップが必要です。)
  8. ^ 日付、CJ(2019)。EFコッドと関係理論:コッドの主要なデータベースの記述の詳細なレビューと分析p。135. ISBN 978-1684705276
  9. ^ 日付、CJ; コッド、EF(1975年1月)。「リレーショナルおよびネットワークアプローチ:アプリケーションプログラミングインターフェイスの比較」。Randall Rustin(ed。)データの説明、アクセス、および制御に関する1974ACM-SIGMODワークショップの議事録SIGMOD Workshop 1974.Vol。2.ミシガン州アナーバー:Association for ComputingMachinery。pp。83–113。土井10.1145 /800297.811532ISBN 978-1450374187OCLC1175623233 _
  10. ^ カール、マラムド(1990)。NovellNetworksの分析。ヴァンノストランドラインホールド。p。294. ISBN 978-0442003647
  11. ^ a b ジン、ブレンダ; Sahni、Saurabh; シェバット、アミール(2018)。WebAPIの設計オライリーメディア。ISBN 9781492026877
  12. ^ フィールディング、ロイ(2000)。建築様式とネットワークベースのソフトウェアアーキテクチャ(PhD)の設計2020年9月18日取得
  13. ^ Dotsika、Fefie(2010年8月)。「セマンティックAPI:セマンティックWebへのスケールアップ」。情報管理の国際ジャーナル30(4):335–342。土井10.1016 /j.ijinfomgt.2009.12.003
  14. ^ Odersky、マーティン; スプーン、レックス; Venners、Bill(2008年12月10日)。「ScalaとJavaの組み合わせ」www.artima.com 2016年7月29日取得
  15. ^ de Figueiredo、ルイス・エンリケ; イエルサリムシー、ロベルト; Filho、Waldemar Celes(1994)。「アプリケーションを拡張するための言語の設計と実装」TeCGraf Grupo de Tecnologia Em Computacao Grafica:273–284。CiteSeerX10.1.1.47.5194_ S2CID59833827 _ 2016年7月29日取得  
  16. ^ シンテス、トニー(2001年7月13日)。「とにかくJavaAPIとは何ですか?」JavaWorld2020年7月18日取得
  17. ^ ウィンターズ、タイタス​​; トム・マンシュレック; ハイラムライト編 (2020)。Googleのソフトウェアエンジニアリング:時間の経過とともにプログラミングから学んだ教訓カリフォルニア州セバストポル。ISBN 9781492082798OCLC1144086840 _
  18. ^ マスタンジェロ、ルイス; ポンザネッリ、ルカ; モッチ、アンドレア; ランザ、ミケーレ; Hauswirth、Matthias; Nystrom、Nathaniel(2015-10-23)。「自己責任で使用してください:実際のJavaの安全でないAPI」。オブジェクト指向プログラミング、システム、言語、およびアプリケーションに関する2015 ACMSIGPLAN国際会議の議事録OOPSLA 2015.ニューヨーク、ニューヨーク、米国:Association for ComputingMachinery。pp。695–710。土井10.1145 /2814270.2814313ISBN 978-1-4503-3689-5
  19. ^ ハランド、ニコラス; ベネララム、アミン; ソトバレロ、セザール; ベッテガ、フランソワ; バレ、オリヴィエ; ボードリー、ブノワ(2022-02-01)。「APIの美しさはクライアントの目にあります。220万のMaven依存関係により、クライアントとAPIの使用の範囲が明らかになります」ジャーナルオブシステムズアンドソフトウェア184:111134。doi 10.1016 /j.jss.2021.111134ISSN0164-1212_ 
  20. ^ Mclaughlin、Stefano(1996年12月20日)。「標準、API、インターフェース、バインディングについて知っておくべきこと」Washingtonindependent.com。
  21. ^ 「F2PY.org」F2PY.org 2011年12月18日取得
  22. ^ ファウラー、マーティン。「制御の反転」
  23. ^ ファヤド、モハメド。「オブジェクト指向アプリケーションフレームワーク」
  24. ^ Lewine、Donald A.(1991)。POSIXプログラマーガイドO'Reilly&Associates、Inc.p。1.ISBN _ 97809371757362016年8月2日取得
  25. ^ ウェスト、ジョエル; デドリック、ジェイソン(2001)。「オープンソースの標準化:ネットワーク時代のLinuxの台頭」(PDF)知識、技術、ポリシー14(2):88–112 2016年8月2日取得
  26. ^ マイクロソフト(2001年10月)。「WindowsXPのサポート」マイクロソフト。p。4. 2009年9月26日にオリジナルからアーカイブされました。
  27. ^ 「LSBの紹介」LinuxFoundation。2012年6月21日2015年3月27日取得
  28. ^ Stoughton、Nick(2005年4月)。「規格の更新」(PDF)USENIX 2009年6月4日取得
  29. ^ ビアホフ、ケビン(2009年4月23日)。「オブジェクト指向ソフトウェアにおけるAPIプロトコルコンプライアンス」(PDF)CMUインスティテュートフォーソフトウェアリサーチ2016年7月29日取得
  30. ^ Wilson、M。Jeff(2000年11月10日)。「プロキシとRMIで賢くなりましょう」JavaWorld2020年7月18日取得
  31. ^ ヘニング、ミチ; Vinoski、Steve(1999)。C ++を使用した高度なCORBAプログラミングアディソン-ウェスリーISBN 978-02013792732015年6月16日取得
  32. ^ 「API-fication」(PDFダウンロード)www.hcltech.com2014年8月。
  33. ^ ベンスリマン、ジャマル; シャフラム・ドゥスター; アミットシェス(2008)。「サービスマッシュアップ:新世代のWebアプリケーション」IEEEインターネットコンピューティング、vol。12、いいえ。5電気電子技術者協会。pp。13–15。2011年9月28日にオリジナルからアーカイブされまし2019-10-01を取得しました。
  34. ^ Niccolai、James(2008-04-23)、「とにかく、エンタープライズマッシュアップとは何ですか?」PCワールド
  35. ^ パー、ベン(2009年5月21日)。「ソーシャルメディアAPIの進化」Mashable 2016年7月26日取得
  36. ^ 「GETトレンド/場所」developer.twitter.com 2020年4月30日取得
  37. ^ パーナス、DL(1972)。「システムをモジュールに分解する際に使用される基準について」。ACMの通信15(12):1053-1058。土井10.1145 /361598.361623S2CID53856438_ 
  38. ^ ガーラン、デビッド; ショー、メアリー(1994年1月)。「ソフトウェアアーキテクチャ入門」(PDF)ソフトウェア工学と知識工学の進歩1 2016年8月8日取得
  39. ^ de Ternay、Guerric(2015年10月10日)。「ビジネスエコシステム:経済的な堀の作成」BoostCompanies 2016年2月1日取得
  40. ^ ボイド、マーク(2014-02-21)。「プライベート、パートナー、またはパブリック:ビジネスに最適なAPI戦略はどれですか?」ProgrammableWeb 2016年8月2日取得
  41. ^ ワイスブロット、アリソン(2016年7月7日)。「カーサービスAPIはどこにでもありますが、パートナーアプリには何が含まれていますか?」AdExchanger
  42. ^ 「CloudflareAPIv4ドキュメント」cloudflare2020年2月25日2020年2月27日取得
  43. ^ Liew、Zell(2018年1月17日)。「カーサービスAPIはどこにでもありますが、パートナーアプリには何が含まれていますか」スマッシングマガジン2020年2月27日取得
  44. ^ a b Shi、Lin; 中、ハオ; 謝、タオ; 李明州(2011)。APIドキュメントの進化に関する実証的研究ソフトウェア工学への基本的なアプローチに関する国際会議コンピュータサイエンスの講義ノート。6603. pp。416–431。土井10.1007 / 978-3-642-19811-3_29ISBN 978-3-642-19810-62016年7月22日取得
  45. ^ 「guava-libraries– Guava:Java 1.6以降のGoogleコアライブラリ–Googleプロジェクトホスティング」2014-02-04 2014年2月11日取得
  46. ^ オラクル。「APIを非推奨にする方法と時期」JavaSEドキュメント2016年8月2日取得
  47. ^ メンデス、ディエゴ; ボードリー、ブノワ; モンペラス、マーティン(2013)。「オブジェクト指向ソフトウェアのAPI使用における大規模な多様性の経験的証拠」2013 IEEE 13th International Working Conference on Source Code Analysis and Manipulation(SCAM)pp。43–52。arXiv1307.4062土井10.1109 /SCAM.2013.6648183ISBN 978-1-4673-5739-5S2CID6890739 _
  48. ^ 高梨学部長(2020年2月19日)。「アカマイ:サイバー犯罪者は金融サービス会社でAPIを攻撃しています」ベンチャービート2020年2月27日取得
  49. ^ デケル、ウリ; Herbsleb、James D.(2009年5月)。「ナレッジプッシュによるAPIドキュメントの使いやすさの向上」。コンピュータサイエンス学部ソフトウェア研究所CiteSeerX10.1.1.446.4214_ 
  50. ^ パーニン、クリス; トリュード、クリストフ(2011年5月)。「WebでのAPIドキュメントの測定」。Web2SE:25〜30。土井10.1145 /1984701.1984706ISBN 9781450305952S2CID17751901 _
  51. ^ Maalej、Waleed; ロビラード、マーティンP.(2012年4月)。「APIリファレンスドキュメントの知識のパターン」(PDF)ソフトウェアエンジニアリングに関するIEEEトランザクション2016年7月22日取得
  52. ^ Monperrus、Martin; アイヒベルク、マイケル; Tekes、Elif; メジーニ、ミラ(2011年12月3日)。「開発者は何に注意する必要がありますか?APIドキュメントのディレクティブに関する実証的研究」。経験的ソフトウェア工学17(6):703–737。arXiv1205.6363土井10.1007 / s10664-011-9186-4S2CID8174618_ 
  53. ^ 「注釈」サンマイクロシステムズ2011年9月25日にオリジナルからアーカイブされました2011年9月30日取得
  54. ^ Bruch、Marcel; メジーニ、ミラ; モンペラス、マーティン(2010)。「フレームワークの再利用を改善するためのサブクラス化ディレクティブのマイニング」。2010第7回マイニングソフトウェアリポジトリに関するIEEEワーキングカンファレンス(MSR 2010)pp。141–150。CiteSeerX10.1.1.434.15_ 土井10.1109 /msr.2010.5463347ISBN  978-1-4244-6802-7S2CID1026918 _
  55. ^ 「Oracleと私たちが知っているプログラミングの終わり」DrDobbs。2012-05-01 2012年5月9日取得
  56. ^ 「APIは著作権で保護されない」とOracleの場合の裁判官は言うTGDaily。2012-06-01 2012年12月6日取得
  57. ^ 「OracleAmerica、Inc。vs. Google Inc。」(PDF)有線2012-05-31 2013年9月22日取得
  58. ^ 「OracleAm。、Inc.v。GoogleInc。、No。13-1021、Fed。Cir.2014」2014-10-10にオリジナルからアーカイブされました。
  59. ^ ローゼンブラット、セス(2014年5月9日)。「Java特許控訴においてAndroidよりもOracleの法廷側」CNET 2014年5月10日取得
  60. ^ 「GoogleはOracleを打ち負かす–AndroidはJavaAPIの「フェアユース」を行う」ArsTechnica2016-05-26 2016年7月28日取得
  61. ^ デッカー、スーザン(2018年3月27日)。「オラクルがグーグルに対して10億ドルの訴訟の復活を勝ち取る」ブルームバーグビジネスウィーク2018年3月27日取得
  62. ^ リー、ティモシー(2019年1月25日)。「Googleは最高裁判所にAPI著作権に関する悲惨な判決を却下するよう要請している」ArsTechnica2019年2月8日取得
  63. ^ vkimber(2020-09-28)。「GoogleLLCv。OracleAmerica、Inc」LII /リーガルインフォメーションインスティテュート2021-03-06を取得
  64. ^ 「合衆国最高裁判所、No。18–956、GOOGLE LLC、PETITIONERv。ORACLEAMERICA、INC」(PDF)2021年4月5日。

さらに読む

外部リンク