API

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

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

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

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

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

目的

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

用語の歴史

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

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

1940年代と50年代

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年代と70年代

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

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

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

1990年代

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

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

2000年代

2000年にカリフォルニア大学アーバイン校開催されたロイフィールディングの論文ArchitecturalStyles and the Design of Network-based Software ArchitecturesRepresentational State Transfer(REST)の概要を説明し、フィールディングが従来の「ライブラリ-ベースの」API。[12] XMLおよびJSONWeb APIは、2000年に始まり、2021年から継続して広く商業的に採用されました。現在、WebAPIはAPIという用語の最も一般的な意味です。[2]

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

使用法

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

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

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

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

APIの使用は、関連するプログラミング言語のタイプによって異なります。Luaなどの手続き型言語のAPIは、主にコードの実行、データの操作、エラーの処理を行う基本的なルーチンで構成できますが、Javaなどのオブジェクト指向言語のAPIは、クラスとそのクラスメソッドの仕様を提供します[15] [16]

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

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

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

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

APIは、アプリケーションとオペレーティングシステム間のインターフェイスを指定できます[21] POSIXは、例えば、対象のPOSIX準拠オペレーティングシステム用に書かれたアプリケーション有効化することを目指し、共通APIのセットを指定コンパイル別のPOSIX準拠オペレーティングシステム用の。

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

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

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

リモートAPI

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

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

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

Web API

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

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)に移行しています。[30]この傾向の一部は、Webベースのオントロジーエンジニアリング技術を促進するための概念であるResource Description Framework(RDF)へのセマンティックWebの動きに関連しています。 Web APIを使用すると、複数のAPIを組み合わせてマッシュアップと呼ばれる新しいアプリケーションにすることができます[31] ソーシャルメディアの分野では、Web APIにより、Webコミュニティはコミュニティとアプリケーション間でコンテンツとデータを共有しやすくなっています。このようにして、1つの場所で動的に作成されたコンテンツを、Web上の複数の場所に投稿および更新できます。[32]たとえば、TwitterのREST APIを使用すると、開発者はコアTwitterデータにアクセスでき、Search APIは、開発者がTwitterの検索およびトレンドデータを操作するためのメソッドを提供します。[33]

デザイン

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

リリースポリシー

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

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

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

パブリックAPIの意味

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

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

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

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

ドキュメント

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

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

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

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

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

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

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

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

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

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

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

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

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

も参照してください

参考文献

  1. ^ Reddy、Martin(2011)。C ++用のAPIデザインエルゼビアサイエンス。NS。1. ISBN 9780123850041
  2. ^ a b レーン、キン(2019年10月10日)。「APIの概要:APIの歴史」Postman 2020年9月18日取得頭字語「API」またはその拡張バージョン「アプリケーションプログラミングインターフェイス」を聞くと、ほとんどの場合、HTTPを使用してJSONまたはXML形式の機械可読データへのアクセスを提供するという点で最新のアプローチを参照しています。 「WebAPI」と呼ばれます。APIはコンピューティングとほぼ同じくらい長い間存在していましたが、最新のWebAPIは2000年代初頭に形になり始めました。
  3. ^ a b c クラーク、スティーブン(2004)。「APIユーザビリティの測定」ドブ博士の検索された29年7月2016
  4. ^ a b データベースアーキテクチャ–実現可能性ワークショップ(レポート)。ワシントンDC:米国商務省、国立標準局。1981年4月。45〜47ページ。hdl2027 /mdp.39015077587742LCCN 81600004NBS特別刊行物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秋の合同コンピュータ会議。カリフォルニア州サンフランシスコ:Association for ComputingMachinery。pp。533–544。土井10.1145 /1476589.1476661ISBN 978-1450378994OCLC  1175621908
  7. ^ 「アプリケーションプログラムインターフェース」オックスフォード英語辞典(オンライン版)。オックスフォード大学出版局 (サブスクリプションまたは参加機関のメンバーシップが必要です。)
  8. ^ 日付、CJ(2019)。EFコッドと関係理論:コッドの主要なデータベース記述の詳細なレビューと分析NS。135. ISBN 978-1684705276
  9. ^ 日付、CJ; コッド、EF(1975年1月)。「リレーショナルアプローチとネットワークアプローチ:アプリケーションプログラミングインターフェイスの比較」Randall Rustin(ed。)データの説明、アクセス、および制御に関する1974ACM-SIGMODワークショップの議事録SIGMODワークショップ1974年2ミシガン州アナーバー:Association for ComputingMachinery。pp。83–113。土井10.1145 /800297.811532ISBN 978-1450374187OCLC  1175623233
  10. ^ カール、マラムド(1990)。NovellNetworksの分析ヴァンノストランドラインホールド。NS。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、Martin; スプーン、レックス; Venners、Bill(2008年12月10日)。「ScalaとJavaの組み合わせ」www.artima.com 検索された29年7月2016
  15. ^ de Figueiredo、ルイス・エンリケ; イエルサリムシー、ロベルト; Filho、Waldemar Celes(1994)。「アプリケーションを拡張するための言語の設計と実装」TeCGraf Grupo de Tecnologia Em Computacao Grafica:273–284。CiteSeerX 10.1.1.47.5194S2CID 59833827 検索された29年7月2016  
  16. ^ シンテス、トニー(2001年7月13日)。「とにかくJavaAPIとは何ですか?」JavaWorld2020718日取得
  17. ^ エメリー、デビッド。「標準、API、インターフェース、およびバインディング」Acm.org。アーカイブされたオリジナルの2015年1月16日に2016年88日取得
  18. ^ 「F2PY.org」F2PY.org 2011年1218日取得
  19. ^ ファウラー、マーティン。「制御の反転」
  20. ^ ファヤド、モハメド。「オブジェクト指向アプリケーションフレームワーク」
  21. ^ Lewine、Donald A.(1991)。POSIXプログラマーズガイドO'Reilly&Associates、Inc.p。1. ISBN 9780937175736取り出さ年8月2 2016
  22. ^ ウェスト、ジョエル; デドリック、ジェイソン(2001)。「オープンソースの標準化:ネットワーク時代のLinuxの台頭」(PDF)知識、技術、政策14(2):88–112 取り出さ年8月2 2016
  23. ^ マイクロソフト(2001年10月)。「WindowsXPのサポート」マイクロソフト。NS。4. 2009年9月26日にオリジナルからアーカイブされまし
  24. ^ 「LSBの紹介」LinuxFoundation。2012年6月21日2015年3月27日取得
  25. ^ Stoughton、Nick(2005年4月)。「規格の更新」(PDF)USENIX 2009年6月4日取得
  26. ^ ビアホフ、ケビン(2009年4月23日)。「オブジェクト指向ソフトウェアにおけるAPIプロトコルコンプライアンス」(PDF)CMUインスティテュートフォーソフトウェアリサーチ検索された29年7月2016
  27. ^ ウィルソン、M。ジェフ(2000年11月10日)。「プロキシとRMIで賢くなりましょう」JavaWorld2020718日取得
  28. ^ ヘニング、ミチ; Vinoski、Steve(1999)。C ++を使用した高度なCORBAプログラミングアディソン-ウェスリーISBN 978-0201379273検索された16年6月2015年
  29. ^ 「API-fication」(PDFダウンロード)www.hcltech.com2014年8月。
  30. ^ ベンスリマン、ジャマル; シャフラム・ドゥスダー; アミットシェス(2008)。「サービスマッシュアップ:新世代のWebアプリケーション」IEEEインターネットコンピューティング、vol。12、いいえ。5電気電子技術者協会。pp。13–15。2011年9月28日にオリジナルからアーカイブされまし2019-10-01を取得しました
  31. ^ Niccolai、James(2008-04-23)、「とにかく、エンタープライズマッシュアップとは何ですか?」PCワールド
  32. ^ パー、ベン(2009年5月21日)。「ソーシャルメディアAPIの進化」Mashable 検索された26年7月2016
  33. ^ 「GETトレンド/場所」development.twitter.com 2020430日取得
  34. ^ パーナス、DL(1972)。「システムをモジュールに分解する際に使用される基準について」(PDF)ACMの通信15(12):1053-1058。土井10.1145 /361598.361623S2CID 53856438  
  35. ^ ガーラン、デビッド; ショー、メアリー(1994年1月)。「ソフトウェアアーキテクチャ入門」(PDF)ソフトウェア工学と知識工学の進歩1 2016年8月8取得
  36. ^ de Ternay、Guerric(2015年10月10日)。「ビジネスエコシステム:経済的な堀の作成」BoostCompanies 取得した2016年2月1日を
  37. ^ ボイド、マーク(2014-02-21)。「プライベート、パートナー、パブリック:どのAPI戦略がビジネスに最適ですか?」ProgrammableWeb 取り出さ年8月2 2016
  38. ^ ワイスブロット、アリソン(2016年7月7日)。「カーサービスAPIはどこにでもありますが、パートナーアプリには何が含まれていますか?」AdExchanger
  39. ^ 「CloudflareAPIv4ドキュメント」cloudflare2020年2月25日2020年2月27日取得
  40. ^ Liew、Zell(2018年1月17日)。「カーサービスAPIはどこにでもありますが、パートナーアプリには何が含まれていますか」スマッシングマガジン2020年2月27日取得
  41. ^ a b Shi、Lin; 中、ハオ; 謝、タオ; 李明州(2011)。APIドキュメントの進化に関する実証的研究ソフトウェア工学への基本的なアプローチに関する国際会議コンピュータサイエンスの講義ノート。6603pp。416–431。土井10.1007 / 978-3-642-19811-3_29ISBN 978-3-642-19810-6検索された22年7月2016
  42. ^ 「guava-libraries– Guava:Java 1.6以降のGoogleコアライブラリ–Googleプロジェクトホスティング」2014-02-04 取得した2014年2月11日を
  43. ^ オラクル。「APIを非推奨にする方法と時期」JavaSEドキュメント取り出さ年8月2 2016
  44. ^ メンデス、ディエゴ; ボードリー、ブノワ; モンペラス、マーティン(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-5S2CID  6890739
  45. ^ 高梨学部長(2020年2月19日)。「アカマイ:サイバー犯罪者が金融サービス会社のAPIを攻撃しています」ベンチャービート2020年2月27日取得
  46. ^ デケル、ウリ; Herbsleb、James D.(2009年5月)。「ナレッジプッシュによるAPIドキュメントのユーザビリティの向上」。コンピュータサイエンス学部ソフトウェア研究所CiteSeerX 10.1.1.446.4214 
  47. ^ パーニン、クリス; トリュード、クリストフ(2011年5月)。「WebでのAPIドキュメントの測定」Web2SE:25〜30。土井10.1145 /1984701.1984706ISBN 9781450305952S2CID  17751901 検索された22年7月2016
  48. ^ Maalej、Waleed; Robillard、Martin P.(2012年4月)。「APIリファレンスドキュメントの知識のパターン」(PDF)ソフトウェアエンジニアリングに関するIEEEトランザクション検索された22年7月2016
  49. ^ モンペラス、マーティン; アイヒベルク、マイケル; Tekes、Elif; メジーニ、ミラ(2011年12月3日)。「開発者は何に注意する必要がありますか?APIドキュメントのディレクティブに関する実証的研究」。経験的ソフトウェア工学17(6):703–737。arXiv1205.6363土井10.1007 / s10664-011-9186-4S2CID 8174618 
  50. ^ 「注釈」サンマイクロシステムズ2011年9月25日にオリジナルからアーカイブされまし20119月30日取得
  51. ^ Bruch、Marcel; メジーニ、ミラ; モンペラス、マーティン(2010)。「フレームワークの再利用を改善するためのサブクラス化ディレクティブのマイニング」。2010第7回マイニングソフトウェアリポジトリに関するIEEEワーキングカンファレンス(MSR 2010)pp。141–150。CiteSeerX 10.1.1.434.15土井10.1109 /msr.2010.5463347ISBN  978-1-4244-6802-7S2CID  1026918
  52. ^ 「Oracleと私たちが知っているプログラミングの終わり」DrDobbs。2012-05-01 2012年5月9取得
  53. ^ 「APIを著作権で保護することはできません」と裁判官は言いますTGDaily。2012-06-01 2012年12月6取得
  54. ^ 「OracleAmerica、Inc。vs. Google Inc。」(PDF)有線2012-05-31 取得した2013年9月22日を
  55. ^ 「OracleAm。、Inc.v。GoogleInc。、No。13-1021、Fed。Cir.2014」
  56. ^ ローゼンブラット、セス(2014年5月9日)。「Java特許控訴においてAndroidよりもOracleの法廷側」CNET 2014年5月10日取得
  57. ^ 「GoogleはOracleを打ち負かします–AndroidはJavaAPIを「フェアユース」します」ArsTechnica2016-05-26 2016年728日取得
  58. ^ デッカー、スーザン(2018年3月27日)。「オラクルがグーグルに対する10億ドルの訴訟の復活を勝ち取る」ブルームバーグビジネスウィーク2018年3月27日取得
  59. ^ リー、ティモシー(2019年1月25日)。「Googleは最高裁判所にAPI著作権に関する悲惨な判決を却下するよう要請している」ArsTechnica2019年2月8日取得
  60. ^ vkimber(2020-09-28)。「GoogleLLC対OracleAmerica、Inc」LII /リーガルインフォメーションインスティテュート2021-03-06を取得しました
  61. ^ 「合衆国最高裁判所、No。18–956、GOOGLE LLC、PETITIONERv。ORACLEAMERICA、INC」(PDF)2021年4月5日。

さらに読む

外部リンク