Jump to content

API: Difference between revisions

From Wikipedia, the free encyclopedia
Browse history interactively
← Previous edit
Content deleted Content added
VisualWikitext
I just added an s to make 'include' consistent in case with 'specifications', in the seventh line down from top.
 
Line 1: Line 1:
{{short description|Connection between computers or programs}}
{{selfref|For the MediaWiki (the software used by Wikipedia) API, see [[mw:API]]}}
{{other uses}}
{{redirect|API|otheruses|API (disambiguation)}}
{{hatnote|"Api.php" redirects here. For the Wikipedia API, see {{Plain link|[Special:ApiHelp]}}.|selfref=true}}


An '''application programming interface''' ('''API''') is a connection between [[computer]]s or between [[computer program]]s. It is a type of software [[Interface (computing)|interface]], offering a service to other pieces of [[software]].<ref>{{cite book |last=Reddy |first=Martin |author-link= |date=2011 |title=API Design for C++ |url=https://books.google.com/books?id=IY29LylT85wC |publisher=Elsevier Science |page=1 |isbn=9780123850041}}</ref> A document or standard that describes how to build such a connection or interface is called an ''API specification''. A computer system that meets this standard is said to ''implement'' or ''expose'' an API. The term API may refer either to the specification or to the implementation.
In [[computer programming]], an '''application programming interface''' ('''API''') is a set of [[subroutine]] definitions, protocols, and tools for building [[Software applications|software and applications.]] A good API makes it easier to develop a program by providing all the building blocks, which are then put together by the programmer.

An API may be for a web-based system, operating system, database system, [[computer hardware]], or [[Library (computing)|software library]].
In contrast to a [[user interface]], which connects a computer to a person, an application programming interface connects computers or pieces of software to each other. It is not intended to be used directly by a person (the [[end user]]) other than a [[computer programmer]] who is incorporating it into software. An API is often made up of different parts which act as tools or services that are available to the programmer. A program or a programmer that uses one of these parts is said to ''call'' that portion of the API. The calls that make up the API are also known as [[subroutine]]s, methods, requests, or [[communication endpoint|endpoint]]s. An API specification ''defines'' these calls, meaning that it explains how to use or implement them.
An API specification can take many forms, but often includes specifications for [[subroutine|routines]], [[data structure]]s, [[Class (computer programming)|object classes]], variables, or [[Remote procedure call|remote calls]]. [[POSIX]], [[Microsoft]] [[Windows API]], the [[C++]] [[Standard Template Library]], and [[List of Java APIs|Java API]]s are examples of different forms of APIs.

Documentation for the API is usually provided to facilitate usage.
One purpose of APIs is to [[information hiding|hide the internal details]] of how a system works, exposing only those parts a programmer will find useful and keeping them consistent even if the internal details later change. An API may be custom-built for a particular pair of systems, or it may be a shared standard allowing [[interoperability]] among many systems.
The status of APIs in [[intellectual property]] law is controversial.

The term API is often used to refer to [[web API]]s,<ref name="Lane2019"/> which allow communication between computers that are joined by the [[internet]]. There are also APIs for [[programming language]]s, [[library (computing)|software libraries]], computer [[operating system]]s, and [[computer hardware]]. APIs originated in the 1940s, though the term did not emerge until the 1960s and 70s.


== Purpose ==
== Purpose ==
An API opens a software system to interactions from the outside. It allows two software systems to communicate across a boundary {{mdash}} an interface {{mdash}} using mutually agreed-upon signals.<ref name=Pedro2024>{{cite book |title=Building an API Product: Design, Implement, Release, and Maintain API Products that Meet User Needs |first=Bruno |last=Pedro |year=2024 |page=4 |publisher=Packt Publishing |isbn=9781837638536 |url=https://books.google.com/books?id=JfbuEAAAQBAJ }}</ref> In other words, an API connects software entities together. Unlike a [[user interface]], an API is typically not visible to users. It is an "under the hood" portion of a software system, used for machine-to-machine communication.<ref>{{cite book |title=RESTful API Design |first=Matthias |last=Biehl |year=2016 |page=10 |publisher=API-University Press |isbn=9781514735169 }}</ref>
Just as a [[graphical user interface]] makes it easier for people to use programs, application programming interfaces make it easier for [[Software developer|developers]] to use certain technologies in building applications.
By [[Abstraction (software engineering)|abstracting]] the underlying implementation and only exposing objects or actions the developer needs, an API reduces the cognitive load on a programmer.
While a graphical interface for an [[email client]] might provide a user with a button that performs all the steps for fetching and highlighting new emails, an API for file [[input/output]] might give the developer a [[Subroutine|function]] that copies a file from one location to another without requiring that the developer understand the [[File system journaling|file system]] operations occurring behind the scenes.<ref name="Clarke4">{{cite web|last1=Clarke|first1=Steven|title=Measuring API Usability|url=http://www.drdobbs.com/windows/measuring-api-usability/184405654|website=Dr. Dobb's|accessdate=29 July 2016|date=2004}}</ref>


A well-designed API exposes only objects or actions needed by software or software developers. It hides details that have no use. This [[Abstraction (software engineering)|abstraction]] simplifies programming.<ref name="Clarke4">{{Cite web |url=http://www.drdobbs.com/windows/measuring-api-usability/184405654 |title=Measuring API Usability |last=Clarke |first=Steven |date=2004 |website=Dr. Dobb's |access-date=29 July 2016}}</ref>
== Uses ==

[[File:LEGO-kompatiblo.jpg|thumb|Metaphorically, APIs connect software like interlocking blocks. ]]
Building software using APIs has been compared to using building-block toys, such as [[Lego]] bricks. Software services or software libraries are analogous to the bricks; they may be joined together via their APIs, composing a new software product.<ref>{{cite book |title=Designing Web APIs: Building APIs That Developers Love |first1=Brenda |last1=Jin |first2=Saurabh |last2=Sahni |first3=Amir |last3=Shevat |isbn=9781492026877 |year=2018 |publisher=O'Reilly Media |chapter=Preface |url=https://books.google.com/books?id=Dg1rDwAAQBAJ }}</ref> The process of joining is called ''integration''.<ref name=Pedro2024 />

As an example, consider a weather sensor that offers an API. When a certain message is transmitted to the sensor, it will detect the current weather conditions and reply with a weather report. The message that activates the sensor is an API ''call'', and the weather report is an API ''response''.<ref>{{cite book |title=API Design Patterns
|first=JJ |last=Geewax |year=2021 |page=6 |isbn=9781638350330 |publisher=Manning |url=https://books.google.com/books?id=ato2EAAAQBAJ }}</ref> A weather forecasting app might integrate with a number of weather sensor APIs, gathering weather data from throughout a geographical area.

An API is often compared to a [[contract]]. It represents an agreement between parties: a service provider who offers the API and the software developers who rely upon it. If the API remains stable, or if it changes only in predictable ways, developers' confidence in the API will increase. This may increase their use of the API.<ref>{{cite book |title=APIs: A Strategy Guide |first1=Daniel |last1=Jacobson |first2=Greg |last2=Brail |first3=Dan |last3=Woods |publisher=O'Reilly Media |year=2011 |isbn=9781449321642 |page=4 |url=https://books.google.com/books?id=om5tNwKW4xkC}}</ref>

== History of the term ==

[[File:Database_management_system_diagram_from_1978_workshop.png|thumb|left|A diagram from 1978 proposing the expansion of the idea of the API to become a general programming interface, beyond [[application program]]s alone<ref name="NBS1981" />]]
The term ''API'' initially described an interface only for end-user-facing programs, known as [[application program]]s. This origin is still reflected in the name "application programming interface." Today, the term is broader, including also [[utility software]] and even [[Hardware interface design|hardware interfaces]].<ref name="Bloch2018" />

The idea of the API is much older than the term itself. British computer scientists [[Maurice Wilkes]] and [[David Wheeler (computer scientist)|David Wheeler]] worked on a modular [[software library]] in the 1940s for [[EDSAC]], an early computer. The [[subroutine]]s in this library were stored on [[punched paper tape]] organized in a [[filing cabinet]]. This cabinet also contained what Wilkes and Wheeler called a "library catalog" of notes about each subroutine and how to incorporate it into a program. Today, such a catalog would be called an API (or an API specification or API documentation) because it instructs a programmer on how to use (or "call") each subroutine that the programmer needs.<ref name="Bloch2018" />

Wilkes and Wheeler's book ''[[The Preparation of Programs for an Electronic Digital Computer]]'' contains the first published API specification. [[Joshua Bloch]] considers that Wilkes and Wheeler "latently invented" the API, because it is more of a concept that is discovered than invented.<ref name="Bloch2018">{{cite speech |last=Bloch |first=Joshua |author-link=Joshua Bloch |title=A Brief, Opinionated History of the API |event=QCon |date=August 8, 2018 |location=San Francisco |publisher=InfoQ |url=https://www.infoq.com/presentations/history-api/ |access-date=September 18, 2020}}</ref>

[[File:Univac 1108 Census Bureau.jpg|thumb|300px|Although the people who coined the term API were implementing software on a [[UNIVAC 1100/2200 series#1108|Univac 1108]], the goal of their API was to make [[hardware independent]] programs possible.<ref name="CottonGreatorex1968" />]]
The term "application program interface" (without an ''-ing'' suffix) is first recorded in a paper called ''Data structures and techniques for remote [[computer graphics]]'' presented at an [[AFIPS]] conference in 1968.<ref>{{Cite OED|application program interface}}</ref><ref name="Bloch2018" /> The authors of this paper use the term to describe the interaction of an [[application software|application]]—a graphics program in this case—with the rest of the computer system. A consistent application interface (consisting of [[Fortran]] subroutine calls) was intended to free the programmer from dealing with idiosyncrasies of the graphics display device, and to provide [[hardware independence]] if the computer or the display were replaced.<ref name="CottonGreatorex1968">{{cite conference |url=https://www.computer.org/csdl/pds/enwiki/api/csdl/proceedings/download-article/12OmNyRPgFZ/pdf |title=Data structures and techniques for remote computer graphics |last1=Cotton |first1=Ira W. |last2=Greatorex |first2=Frank S. |date=December 1968 |conference=AFIPS 1968 Fall Joint Computer Conference |volume=I |book-title=AFIPS '68: Proceedings of the December 9–11, 1968, Fall Joint Computer Conference |publisher=Association for Computing Machinery |location=San Francisco, California |pages=533–544 |isbn=978-1450378994 |oclc= 1175621908 |doi=10.1145/1476589.1476661 }}</ref>

The term was introduced to the field of [[database]]s by [[Christopher J. Date|C. J. Date]]<ref>{{cite book |last=Date |first=C. J. |author-link=Christopher J. Date |year=2019 |title=E. F. Codd and Relational Theory: A Detailed Review and Analysis of Codd's Major Database Writings |url=https://books.google.com/books?id=2Sy4DwAAQBAJ&pg=PA135 |page=135 |publisher=Lulu.com |isbn=978-1684705276}}</ref> in a 1974 paper called ''The [[Relational database|Relational]] and [[Network model|Network]] Approaches: Comparison of the Application Programming Interface''.<ref>{{cite conference |url=https://dl.acm.org/doi/pdf/10.1145/800297.811532 |title=The relational and network approaches: Comparison of the application programming interfaces |last1=Date |first1=C. J. |last2=Codd |first2=E. F. |date=January 1975 |editor=Randall Rustin |conference=SIGMOD Workshop 1974 |volume=2 |book-title=Proceedings of 1974 ACM-SIGMOD Workshop on Data Description, Access and Control |publisher=Association for Computing Machinery |location=Ann Arbor, Michigan |pages=83–113 |isbn=978-1450374187 |oclc=1175623233 |doi=10.1145/800297.811532 }}</ref> An API became a part of the [[ANSI-SPARC Architecture|ANSI/SPARC framework]] for [[database management system]]s. This framework treated the application programming interface separately from other interfaces, such as the query interface. Database professionals in the 1970s observed these different interfaces could be combined; a sufficiently rich application interface could support the other interfaces as well.<ref name="NBS1981">{{cite report |date=April 1981 |title=Database architectures – a feasibility workshop |url=https://hdl.handle.net/2027/mdp.39015077587742?urlappend=%3Bseq=53 |publisher=U.S. Department of Commerce, National Bureau of Standards |pages=45–47 |access-date=September 18, 2020 |location=Washington, DC|hdl=2027/mdp.39015077587742?urlappend=%3Bseq=53 |id=NBS special publication 500-76 |lccn=81600004}}</ref>

This observation led to APIs that supported all types of programming, not just application programming. By 1990, the API was defined simply as "a set of services available to a programmer for performing certain tasks" by technologist [[Carl Malamud]].<ref>{{cite book |last=Carl |first=Malamud |author-link=Carl Malamud |date=1990 |title=Analyzing Novell Networks |url=https://babel.hathitrust.org/cgi/pt?id=mdp.39015018454903&seq=314 |publisher=Van Nostrand Reinhold |page=294 |isbn=978-0442003647}}</ref>

[[File:Screenshot of NASA API documentation.png|thumb|Screenshot of [[Web API]] documentation written by [[NASA]]]]
The idea of the API was expanded again with the dawn of [[remote procedure calls]] and [[web API]]s. As [[computer network]]s became common in the 1970s and 80s, programmers wanted to call libraries located not only on their local computers, but on computers located elsewhere. These remote procedure calls were well supported by the [[Java (programming language)|Java]] language in particular. In the 1990s, with the spread of the [[internet]], standards like [[CORBA]], [[Component Object Model|COM]], and [[Distributed Component Object Model|DCOM]] competed to become the most common way to expose API services.<ref name="JinSahniShevat2018">{{cite book |first1=Brenda |last1=Jin |first2=Saurabh |last2=Sahni |first3=Amir |last3=Shevat |year=2018 |title=Designing Web APIs |url=https://books.google.com/books?id=Dg1rDwAAQBAJ |location= |publisher=O'Reilly Media |isbn=9781492026877}}</ref>

[[Roy Fielding]]'s dissertation ''Architectural Styles and the Design of Network-based Software Architectures'' at [[UC Irvine]] in 2000 outlined [[Representational state transfer]] (REST) and described the idea of a "network-based Application Programming Interface" that Fielding contrasted with traditional "library-based" APIs.<ref>{{cite thesis |last=Fielding |first=Roy |date=2000 |title=Architectural Styles and the Design of Network-based Software Architectures |type=PhD |url=https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm |access-date=September 18, 2020}}</ref> [[XML]] and [[JSON]] web APIs saw widespread commercial adoption beginning in 2000 and continuing as of 2021. The web API is now the most common meaning of the term API.<ref name="Lane2019">{{cite web |url=https://blog.postman.com/intro-to-apis-history-of-apis/ |title=Intro to APIs: History of APIs |last=Lane |first=Kin |date=October 10, 2019 |website=Postman |access-date=September 18, 2020 |quote=When you hear the acronym “API” or its expanded version “Application Programming Interface,” it is almost always in reference to our modern approach, in that we use HTTP to provide access to machine readable data in a JSON or XML format, often simply referred to as “web APIs.” APIs have been around almost as long as computing, but modern web APIs began taking shape in the early 2000s.}}</ref>

The [[Semantic Web]] proposed by [[Tim Berners-Lee]] in 2001 included "semantic APIs" that recast the API as an [[open innovation|open]], distributed data interface rather than a software behavior interface.<ref>{{cite journal |last1=Dotsika |first1=Fefie |date=August 2010 |title=Semantic APIs: Scaling up towards the Semantic Web |journal=International Journal of Information Management |volume=30 |issue=4 |pages=335–342 |doi=10.1016/j.ijinfomgt.2009.12.003 }}</ref> [[proprietary software|Proprietary]] interfaces and agents became more widespread than open ones, but the idea of the API as a data interface took hold. Because web APIs are widely used to exchange data of all kinds online, API has become a broad term describing much of the communication on the internet.<ref name="JinSahniShevat2018" /> When used in this way, the term API has overlap in meaning with the term [[communication protocol]].

== Types ==


===Libraries and frameworks===
===Libraries and frameworks===
An API is usually related to a [[software library]]: the API describes and prescribes the ''expected behavior'' while the library is an ''actual implementation'' of this set of rules.
The interface to a [[library (computing)|software library]] is one type of API. The API describes and prescribes the "expected behavior" (a specification) while the library is an "actual implementation" of this set of rules.

A single API can have multiple implementations (or none, being abstract) in the form of different libraries that share the same programming interface.
A single API can have multiple implementations (or none, being abstract) in the form of different libraries that share the same programming interface.

The separation of the API from its implementation can allow programs written in one language to use a library written in another.
For example, because [[Scala (programming language)|Scala]] and [[Scala (programming language)|Java]] compile to compatible [[bytecode]], Scala developers can take advantage of any Java API.<ref name="OderskySpoonVenners8">{{cite web|last1=Odersky|first1=Martin|last2=Spoon|first2=Lex|last3=Venners|first3=Bill|title=Combining Scala and Java|url=http://www.artima.com/pins1ed/combining-scala-and-java.html|website=www.artima.com|accessdate=29 July 2016|date=10 December 2008}}</ref>
The separation of the API from its implementation can allow programs written in one language to use a library written in another. For example, because [[Scala (programming language)|Scala]] and [[Java (programming language)|Java]] compile to compatible [[bytecode]], Scala developers can take advantage of any Java API.<ref name="OderskySpoonVenners8">{{Cite web |url=http://www.artima.com/pins1ed/combining-scala-and-java.html |title=Combining Scala and Java |last1=Odersky |first1=Martin |last2=Spoon |first2=Lex |date=10 December 2008 |website=www.artima.com |access-date=29 July 2016 |last3=Venners |first3=Bill}}</ref>


API use can vary depending on the type of programming language involved.
API use can vary depending on the type of programming language involved.
An API for a procedural language such as [[Lua (programming language)|Lua]] could primarily consist of basic routines to execute code, manipulate data, or handle errors, while an API for an object oriented language such as [[Java]] would provide a specification of classes and their [[class method]]s.<ref>{{cite journal|last1=de Figueiredo|first1=Luiz Henrique|last2=Ierusalimschy|first2=Roberto|last3=Filho|first3=Waldemar Celes|title=The design and implementation of a language for extending applications|journal=TeCGraf Grupo de Tecnologia em Computacao Grafica|url=https://www.researchgate.net/profile/Waldemar_Celes/publication/2778436_The_Design_and_Implementation_of_a_Language_for_Extending_Applications/links/00b7d522f51ad361f9000000.pdf|accessdate=29 July 2016}}</ref><ref name="Sintes16">{{cite web|last1=Sintes|first1=Tony|title=Just what is the Java API anyway?|url=http://www.javaworld.com/article/2077392/java-se/just-what-is-the-java-api-anyway.html|website=JavaWorld|accessdate=29 July 2016}}</ref>
An API for a [[procedural programming|procedural language]] such as [[Lua (programming language)|Lua]] could consist primarily of basic routines to execute code, manipulate data or handle errors while an API for an [[object-oriented programming|object-oriented language]], such as Java, would provide a specification of classes and its [[class method]]s.<ref>{{cite conference |last1=de Figueiredo |first1=Luiz Henrique |author-link2=Roberto Ierusalimschy |last2=Ierusalimschy |first2=Roberto |last3=Filho |first3=Waldemar Celes |title=The design and implementation of a language for extending applications |url=https://www.lua.org/semish94.html |book-title=Proceedings of XXI Brazilian Seminar on Software and Hardware |year=1994 |pages=273–284 |citeseerx=10.1.1.47.5194 |s2cid=59833827 |access-date=29 July 2016}}</ref><ref name="Sintes16">{{cite web |last1=Sintes |first1=Tony |date=2001-07-13 |df=dmy |url=https://www.infoworld.com/article/2077392/just-what-is-the-java-api-anyway.html |title=Just what is the Java API anyway? |website=[[JavaWorld]] |access-date=2020-07-18}}</ref> {{Visible anchor|Hyrums|text=Hyrum's law states that "With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody."}}<ref>{{Cite book|editor-last=Winters|editor-first=Titus |title=Software engineering at Google: lessons learned from programming over time|date=2020|editor2=Tom Manshreck |editor3=Hyrum Wright|isbn=9781492082798 |location=Sebastopol, CA|oclc=1144086840 |publisher=O'Reilly Media}}</ref> Meanwhile, several studies show that most applications that use an API tend to use a small part of the API.<ref>{{Cite conference |last1=Mastrangelo |first1=Luis |last2=Ponzanelli |first2=Luca |last3=Mocci |first3=Andrea |last4=Lanza |first4=Michele |last5=Hauswirth |first5=Matthias |last6=Nystrom |first6=Nathaniel |date=2015-10-23 |title=Use at your own risk: the Java unsafe API in the wild |book-title=Proceedings of the 2015 ACM SIGPLAN International Conference on Object-Oriented Programming, Systems, Languages, and Applications |location=New York, New York, U.S. |publisher=Association for Computing Machinery |pages=695–710 |doi=10.1145/2814270.2814313 |isbn=978-1-4503-3689-5}}</ref>

[[Language binding]]s are also APIs. By mapping the features and capabilities of one language to an interface implemented in another language, a language binding allows a library or service written in one language to be used when developing in another language.<ref name="Emery">{{Cite web |url=http://www.acm.org/tsc/apis.html |title=Standards, APIs, Interfaces and Bindings |last=Emery |first=David |publisher=Acm.org |url-status=dead |archive-url=https://web.archive.org/web/20150116081559/http://www.acm.org/tsc/apis.html |archive-date=2015-01-16 |access-date=2016-08-08}}</ref> Tools such as [[SWIG]] and F2PY, a [[Fortran]]-to-[[Python (programming language)|Python]] interface generator, facilitate the creation of such interfaces.<ref>{{Cite web |url=http://www.f2py.org/ |title=F2PY.org |publisher=F2PY.org |access-date=2011-12-18}}</ref>


An API can also be related to a [[Framework (computer science)|software framework]]: a framework can be based on several libraries implementing several APIs, but unlike the normal use of an API, the access to the behavior built into the framework is mediated by extending its content with new classes plugged into the framework itself.
[[Language binding]]s are also APIs. By mapping the features and capabilities of one language to an interface implemented in another language, a language binding allows a library or service written in one language to be used when developing in another language.<ref name=Emery>{{cite web|url=http://www.acm.org/tsc/apis.html |last1=Emery|first1=David|title=Standards, APIs, Interfaces and Bindings |publisher=Acm.org |date= |accessdate=2016-08-08}}</ref><ref name=cairo>{{cite web|url=http://www.cairographics.org/manual/language-bindings.html |title=Appendix A. Creating a language binding for cairo |publisher=Cairographics.org |date= |accessdate=2016-08-08}}</ref>
Tools such as [[SWIG]] and F2PY, a [[Fortran]] to [[Python (programming language)|Python]] interface generator, facilitate the creation of such interfaces.<ref>{{cite web|url=http://www.f2py.org/ |title=F2PY.org |publisher=F2PY.org |accessdate=2011-12-18}}</ref>


Moreover, the overall program flow of control can be out of the control of the caller and in the framework's hands by [[inversion of control]] or a similar mechanism.<ref>{{cite web
An API can also be related to a [[Framework (computer science)|software framework]]: a framework can be based on several libraries implementing several APIs, but unlike the normal use of an API, the ''access'' to the behavior ''built into the framework'' is [[Data transformation|mediated]] by extending its content with new classes plugged into the framework itself.
Moreover, the overall program flow of control can be out of the control of the caller, and in the hands of the framework via [[inversion of control]] or a similar mechanism.<ref>{{cite web
|first = Martin
|first = Martin
|last = Fowler
|last = Fowler
Line 42: Line 77:
</ref>
</ref>


===Operating Systems===
===Operating systems===
An API can specify the interface between an application and the [[operating system]].<ref name="Oreilly91">{{cite book|last1=Lewine|first1=Donald A.|title=POSIX Programmer's Guide|date=1991|publisher=O'Reilly & Associates, Inc.|page=1|url=ftp://gamma.sbin.org/pub/doc/books/OReilly_-_POSIX_Programmers_Guide.pdf|accessdate=2 August 2016}}</ref>
An API can specify the interface between an application and the [[operating system]].<ref name="Oreilly91">{{Cite book |last=Lewine |first=Donald A. |url=http://shop.oreilly.com/product/9780937175736.do |title=POSIX Programmer's Guide |date=1991 |publisher=O'Reilly & Associates, Inc. |page=1 |isbn=9780937175736 |access-date=2 August 2016}}</ref> [[POSIX]], for example, specifies a set of common APIs that aim to enable an application written for a POSIX conformant operating system to be [[Compiler|compiled]] for another POSIX conformant operating system.
[[POSIX]], for example, specifies a set of common APIs that aims to enable an application written for a POSIX conformant operating system to be [[Compiler|compiled]] for another POSIX conformant operating system.
[[Linux]] and [[Berkeley Software Distribution]] are examples of operating systems that implement the POSIX APIs.<ref name="WestDedrick16">{{cite journal|last1=West|first1=Joel|last2=Dedrick|first2=Jason|title=Open source standardization: the rise of Linux in the network era|journal=Knowledge, Technology & Policy|date=2001|volume=14|issue=2|pages=88–112|url=http://www.joelwest.org/Papers/WestDedrick2001b.pdf|accessdate=2 August 2016|publisher=Springer}}</ref>


[[Linux]] and [[Berkeley Software Distribution]] are examples of operating systems that implement the POSIX APIs.<ref name="WestDedrick16">{{Cite journal |last1=West |first1=Joel |last2=Dedrick |first2=Jason |date=2001 |title=Open source standardization: the rise of Linux in the network era |url=http://www.joelwest.org/Papers/WestDedrick2001b.pdf |journal=Knowledge, Technology & Policy |volume=14 |issue=2 |pages=88–112 |doi=10.1007/PL00022278 |access-date=2 August 2016}}</ref>
[[Microsoft]] has shown a strong commitment to a backward compatible API, particularly within their [[Windows API]] (Win32) library, such that older applications may run on newer versions of Windows using an executable-specific setting called "Compatibility Mode".<ref>

[[Microsoft]] has shown a strong commitment to a backward-compatible API, particularly within its [[Windows API]] (Win32) library, so older applications may run on newer versions of Windows using an executable-specific setting called "Compatibility Mode".<ref>
{{cite web
{{cite web
|author=Microsogt
|author=Microsoft
|url=http://www.microsoft.com/windowsxp/using/helpandsupport/learnmore/appcompat.mspx
|url=http://www.microsoft.com/windowsxp/using/helpandsupport/learnmore/appcompat.mspx
|title=Support for Windows XP
|title=Support for Windows XP
|publisher=Microsoft
|publisher=Microsoft
|page=4
|page=4
|date=October 2001
|date=October 2001
|url-status=dead
|deadurl=yes
|archiveurl=https://web.archive.org/web/20090926235439/http://www.microsoft.com:80/windowsxp/using/helpandsupport/learnmore/appcompat.mspx
|archive-url=https://web.archive.org/web/20090926235439/http://www.microsoft.com/windowsxp/using/helpandsupport/learnmore/appcompat.mspx
|archivedate=2009-09-26
|archive-date=2009-09-26
|df=
}}</ref>
}}</ref>


An API differs from an [[application binary interface]] (ABI) in that an API is source code based while an ABI is [[Binary file | binary]] based. For instance [[POSIX]] provides APIs, while the [[Linux Standard Base]] provides an ABI.<ref>{{cite web|
An API differs from an [[application binary interface]] (ABI) in that an API is source code based while an ABI is [[Binary file|binary]] based. For instance, [[POSIX]] provides APIs while the [[Linux Standard Base]] provides an ABI.<ref>{{cite web|
url=http://www.linuxfoundation.org/collaborate/workgroups/lsb/lsb-introduction|
url=http://www.linuxfoundation.org/collaborate/workgroups/lsb/lsb-introduction|
title=LSB Introduction|
title=LSB Introduction|
publisher=Linux Foundation|date=21 June 2012|
publisher=Linux Foundation|date=21 June 2012|
accessdate=2015-03-27}}</ref><ref>{{cite web|
access-date=2015-03-27|
archive-url=https://web.archive.org/web/20150402094250/http://www.linuxfoundation.org/collaborate/workgroups/lsb/lsb-introduction|
archive-date=2015-04-02|
url-status=dead}}</ref><ref>{{cite web|
first=Nick|
first=Nick|
last=Stoughton|
last=Stoughton|
url=https://db.usenix.org/publications/login/2005-04/openpdfs/standards2004.pdf|
url=https://db.usenix.org/publications/login/2005-04/openpdfs/standards2004.pdf|
title=Update on Standards|
title=Update on Standards|
publisher=[[USENIX]]|
publisher=[[USENIX]]|date=April 2005|
access-date=2009-06-04}}</ref>
format=PDF|date=April 2005|
accessdate=2009-06-04}}</ref>


===Remote APIs===
===Remote APIs===
Remote APIs allow developers to manipulate remote resources through [[Communications protocol|protocol]]s, specific standards for communication that allow different technologies to work together, regardless of language or platform.
Remote APIs allow developers to manipulate remote resources through [[Communications protocol|protocol]]s, specific standards for communication that allow different technologies to work together, regardless of language or platform.
For example, the Java Database Connectivity API allows developers to query many different types of [[database]]s with the same set of functions, while the [[Java remote method invocation]] API uses the [[Java Remote Method Protocol]] to allow [[Remote procedure call|invocation]] of functions that operate remotely, but appear local to the developer.<ref name="Bierhoff9">{{cite journal|last1=Bierhoff|first1=Kevin|title=API Protocol Compliance in Object-Oriented Software|journal=CMU Institute for Software Research|date=23 April 2009|url=https://www.cs.cmu.edu/~kbierhof/thesis/bierhoff-thesis.pdf|accessdate=29 July 2016}}</ref><ref name="Wilson16">{{cite web|last1=Wilson|first1=M. Jeff|title=Get smart with proxies and RMI|url=http://www.javaworld.com/javaworld/jw-11-2000/jw-1110-smartproxy.html|website=JavaWorld|accessdate=29 July 2016}}</ref>
For example, the Java Database Connectivity API allows developers to query many different types of [[database]]s with the same set of functions, while the [[Java remote method invocation]] API uses the Java Remote Method Protocol to allow [[Remote procedure call|invocation]] of functions that operate remotely, but appear local to the developer.<ref name="Bierhoff9">{{Cite journal |last=Bierhoff |first=Kevin |date=23 April 2009 |title=API Protocol Compliance in Object-Oriented Software |url=https://www.cs.cmu.edu/~kbierhof/thesis/bierhoff-thesis.pdf |journal=CMU Institute for Software Research |access-date=29 July 2016}}</ref><ref name="Wilson16">{{cite web |last1=Wilson |first1=M. Jeff |date=2000-11-10 |df=dmy |url=https://www.infoworld.com/article/2076234/get-smart-with-proxies-and-rmi.html |title=Get smart with proxies and RMI |work=[[JavaWorld]] |access-date=2020-07-18}}</ref>

Therefore, remote APIs are useful in maintaining the object abstraction in [[object-oriented programming]]; a method call, executed locally on a proxy object, invokes the corresponding method on the remote object, using the remoting protocol, and acquires the result to be used locally as return value.
Therefore, remote APIs are useful in maintaining the object abstraction in [[object-oriented programming]]; a [[method call]], executed locally on a [[Proxy pattern|proxy]] object, invokes the corresponding method on the remote object, using the remoting protocol, and acquires the result to be used locally as a return value.
A modification on the proxy object will also result in a corresponding modification on the remote object.<ref name="AdvancedCorba">{{cite web

|first = Michi
A modification of the proxy object will also result in a corresponding modification of the remote object.<ref name="AdvancedCorba">{{cite book
|last = Henning
|first2 = Steve
|last1 = Henning
|last2 = Vinoski
|first1 = Michi
|last2 = Vinoski
|title = Advanced CORBA Programming with C++
|first2 = Steve
|url = http://www.informit.com/store/advanced-corba-programming-with-c-plus-plus-9780201379273
|year = 1999
|publisher = [[Addison-Wesley]]
|url = https://archive.org/details/advancedcorbapro00henn
|access-date = 16 June 2015
|title = Advanced CORBA Programming with C++
|year = 1999
|publisher = [[Addison-Wesley]]
|ISBN = 978-0201379273}}</ref>
|isbn = 978-0201379273
|url-access = registration
|access-date = 16 June 2015
}}</ref>


===Web APIs===
===Web APIs===
{{Main article|Web API}}
{{Main|Web API}}
Web APIs are the defined interfaces through which interactions happen between an enterprise and applications that use its assets. An API approach is an architectural approach that revolves around providing programmable interfaces to a set of services to different applications serving different types of consumers.<ref>http://www.hcltech.com/sites/default/files/apis_for_dsi.pdf</ref>
Web APIs are the defined interfaces through which interactions happen between an enterprise and applications that use its assets, which also is a [[Service-level agreement|Service Level Agreement]] (SLA) to specify the functional provider and expose the service path or URL for its API users. An API approach is an architectural approach that revolves around providing a program interface to a set of services to different applications serving different types of consumers.<ref>{{Cite web |url=https://www.hcltech.com/sites/default/files/documents/resources/whitepaper/files/apis_for_dsi.pdf |title=API-fication |date=August 2014 |website=www.hcltech.com}}</ref>

When used in the context of [[web development]], an API is typically defined as a set of [[Hypertext Transfer Protocol]] (HTTP) request messages, along with a definition of the structure of response messages, which is usually in an Extensible Markup Language ([[XML]]) or JavaScript Object Notation ([[JSON]]) format. While "web API" historically has been virtually synonymous for [[web service]], the recent trend (so-called [[Web 2.0]]) has been moving away from Simple Object Access Protocol ([[SOAP]]) based web services and [[service-oriented architecture]] (SOA) towards more direct [[representational state transfer]] (REST) style [[web resource]]s and [[resource-oriented architecture]] (ROA).<ref>
When used in the context of [[Web development tools|web development]], an API is typically defined as a set of specifications, such as [[Hypertext Transfer Protocol]] (HTTP) request messages, along with a definition of the structure of response messages, usually in an Extensible Markup Language ([[XML]]) or JavaScript Object Notation ([[JSON]]) format. An example might be a shipping company API that can be added to an eCommerce-focused website to facilitate ordering shipping services and automatically include current shipping rates, without the site developer having to enter the shipper's rate table into a web database. While "web API" historically has been virtually synonymous with [[web service]], the recent trend (so-called [[Web 2.0]]) has been moving away from Simple Object Access Protocol ([[SOAP]]) based web services and [[service-oriented architecture]] (SOA) towards more direct [[representational state transfer]] (REST) style [[web resource]]s and [[resource-oriented architecture]] (ROA).<ref>{{cite journal
{{cite web
|first = Djamal
|first = Djamal
|last = Benslimane
|last = Benslimane
|author2=Schahram Dustdar |author3=Amit Sheth
|author2 = Schahram Dustdar
|author3 = Amit Sheth
|title = Services Mashups: The New Generation of Web Applications
|title = Services Mashups: The New Generation of Web Applications
|doi = 10.1109/MIC.2008.110
|url = http://dsonline.computer.org/portal/site/dsonline/menuitem.9ed3d9924aeb0dcd82ccc6716bbe36ec/index.jsp?&pName=dso_level1&path=dsonline/2008/09&file=w5gei.xml&xsl=article.xsl
|url = https://www.computer.org/csdl/magazine/ic/2008/05/mic2008050013/13rRUytWFdu
|work = IEEE Internet Computing, vol. 12, no. 5
|journal = IEEE Internet Computing
|publisher = Institute of Electrical and Electronics Engineers
|pages = 13–15
|volume = 12
|year = 2008
|issue = 5
|publisher = IEEE
}}
|pages = 13–15
</ref> Part of this trend is related to the [[Semantic Web]] movement toward [[Resource Description Framework]] (RDF), a concept to promote web-based [[ontology engineering]] technologies. Web APIs allow the combination of multiple APIs into new applications known as [[mashup (web application hybrid)|mashup]]s.<ref>
|year = 2008
{{citation
|access-date = 2019-10-01
}}</ref> Part of this trend is related to the [[Semantic Web]] movement toward [[Resource Description Framework]] (RDF), a concept to promote web-based [[ontology engineering]] technologies. Web APIs allow the combination of multiple APIs into new applications known as [[mashup (web application hybrid)|mashup]]s.<ref>{{citation
|first = James
|first = James
|last = Niccolai
|last = Niccolai
|title = So What Is an Enterprise Mashup, Anyway?
|title = So What Is an Enterprise Mashup, Anyway?
|url = http://www.pcworld.com/businesscenter/article/145039/so_what_is_an_enterprise_mashup_anyway.html
|url = https://www.pcworld.com/article/145039/so_what_is_an_enterprise_mashup_anyway.html
|work = [[PC World (magazine)|PC World]]
|work = [[PC World (magazine)|PC World]]
|date = 2008-04-23
|date = 2008-04-23
|access-date = 2017-09-17
}}</ref>
|archive-date = 2017-10-10
In the social media space, web APIs have allowed web communities to facilitate sharing content and data between communities and applications. In this way, content that is created in one place can be dynamically posted and updated in multiple locations on the web.<ref name="Parr16">{{cite web|last1=Parr|first1=Ben|title=The Evolution of the Social Media API|url=http://mashable.com/2009/05/21/social-media-api/#1LJkofEl.Gqi|website=Mashable|accessdate=26 July 2016}}</ref>
|archive-url = https://web.archive.org/web/20171010045104/https://www.pcworld.com/article/145039/article.html
|url-status = dead
}}</ref>
In the social media space, web APIs have allowed web communities to facilitate sharing content and data between communities and applications. In this way, content that is created in one place dynamically can be posted and updated to multiple locations on the web.<ref name="Suffescom Solutions">{{cite web|last1=Parr|first1=Ben|title=mobile app development dubai|url=https://www.suffescom.com/mobile-app-development-company-dubai|website=suffescom|date= 23 May 2021|access-date=26 July 2016}}
</ref> For example, Twitter's REST API allows developers to access core Twitter data and the Search API provides methods for developers to interact with Twitter Search and trends data.<ref>{{Cite web|title=GET trends/place|url=https://developer.twitter.com/en/docs/trends/trends-for-location/api-reference/get-trends-place|website=developer.twitter.com|language=en|access-date=2020-04-30}}</ref>


==Design==
==Design==
The design of an API has significant impact on its usage.<ref name="Clarke4"/> The principle of [[information hiding]] describes the role of programming interfaces as enabling [[modular programming]] by hiding the implementation details of the modules so that users of modules need not understand the complexities inside the modules.<ref name="Parnas72">{{Cite journal |last=Parnas |first=D.L. |date=1972 |title=On the Criteria To Be Used in Decomposing Systems into Modules |url=https://www.win.tue.nl/~wstomv/edu/2ip30/references/criteria_for_modularization.pdf |journal=Communications of the ACM |volume=15 |issue=12 |pages=1053–1058 |doi=10.1145/361598.361623|s2cid=53856438 }}</ref> Thus, the design of an API attempts to provide only the tools a user would expect.<ref name="Clarke4" /> The design of programming interfaces represents an important part of [[software architecture]], the organization of a complex piece of software.<ref name="GarlanShaw94">{{Cite journal |last1=Garlan |first1=David |last2=Shaw |first2=Mary |date=January 1994 |title=An Introduction to Software Architecture |url=https://www.cs.cmu.edu/afs/cs/project/able/ftp/intro_softarch/intro_softarch.pdf |journal=Advances in Software Engineering and Knowledge Engineering |volume=1 |access-date=8 August 2016}}</ref>

The design of an API has significant impacts on its usability.<ref name="Clarke4"/> The principle of [[information hiding]] describes the role of programming interfaces as enabling [[modular programming]] by hiding the implementation details of the modules so that users of modules need not understand the complexities inside the modules.<ref name="Parnas72">{{cite journal|last1=Parnas|first1=D.L.|title=On the Criteria To Be Used in Decomposing Systems into Modules|journal=Association for Computing Machinery|date=1972|url=http://www.cs.umd.edu/class/spring2003/cmsc838p/Design/criteria.pdf|accessdate=8 August 2016}}</ref> Thus, the design of an API attempts to provide only the tools a user would expect.<ref name="Clarke4"/> The design of programming interfaces represents an important part of [[software architecture]], the organization of a complex piece of software.<ref name="GarlanShaw94">{{cite journal|last1=Garlan|first1=David|last2=Shaw|first2=Mary|title=An Introduction to Software Architecture|journal=Advances in Software Engineering and Knowledge Engineering|date=January 1994|volume=1|url=http://www.cs.cmu.edu/afs/cs/project/able/ftp/intro_softarch/intro_softarch.pdf|accessdate=8 August 2016}}</ref>

Several authors have created recommendations for how to design APIs, such as [[Joshua Bloch]],<ref>{{cite web
| last = Bloch
| first = Josh
| title = How to design a good API and why it matters
| url = http://static.googleusercontent.com/media/research.google.com/en//pubs/archive/32713.pdf}}</ref> Kin Lane,<ref>{{Cite web|url=http://pages.3scale.net/rs/516-GHI-083/images/api-provider-guide-api-design.pdf|title=The Industry Guide to API Design|last=Lane|first=Kin|date=2016-03-14|website=|publisher=Kin Lane via 3scale|access-date=2016-03-14}}</ref> and Michi Henning.<ref>{{cite web
| last = Henning
| first = Michi
| url = http://queue.acm.org/detail.cfm?id=1255422
| title = API: Design Matters}}</ref>


==Release policies==
==Release policies==
APIs are one of the most common ways technology companies integrate with each other. Those that provide and use APIs are considered as being members of a business ecosystem.<ref>{{cite web|
APIs are one of the more common ways technology companies integrate. Those that provide and use APIs are considered as being members of a business ecosystem.<ref>{{cite web|
last=de Ternay|
last=de Ternay|
first=Guerric|
first=Guerric|
Line 138: Line 175:
website=BoostCompanies|
website=BoostCompanies|
date=Oct 10, 2015|
date=Oct 10, 2015|
accessdate=2016-02-01}}</ref>
access-date=2016-02-01|
archive-date=2016-09-17|
archive-url=https://web.archive.org/web/20160917121456/https://boostcompanies.com/business-ecosystem/|
url-status=dead}}</ref>


The main policies for releasing an API are:<ref name="Boyd16">{{cite web|last1=Boyd|first1=Mark|title=Private, Partner or Public: Which API Strategy Is Best For Business?|url=http://www.programmableweb.com/news/private-partner-or-public-which-api-strategy-best-business/2014/02/21|website=ProgrammableWeb|accessdate=2 August 2016}}</ref>
The main policies for releasing an API are:<ref name="Boyd16">{{Cite web |url=http://www.programmableweb.com/news/private-partner-or-public-which-api-strategy-best-business/2014/02/21 |title=Private, Partner or Public: Which API Strategy Is Best for Business? |last=Boyd |first=Mark |date=2014-02-21 |website=ProgrammableWeb |access-date=2 August 2016}}</ref>


* Private: The API is for internal company use only.
*<u>Private</u>: The API is for internal company use only.
* Partner: Only specific business partners can use the API. For example, [[Transportation network company|car service companies]] such as [[Uber (company)|Uber]] and [[Lyft]] allow approved third party developers to directly order rides from within their apps. This allows the companies to exercise quality control by curating which apps have access to the API, and provides them with an additional revenue stream.<ref name="Weissbrot16">{{cite web|last1=Weissbrot|first1=Alison|title=Car Service APIs Are Everywhere, But What’s In It For Partner Apps? {{!}} AdExchanger|url=http://adexchanger.com/mobile/car-service-apis-everywhere-whats-partner-apps/|website=ad exchanger|accessdate=2 August 2016|date=7 July 2016}}</ref>
*<u>Partner</u>: Only specific business partners can use the API. For example, [[vehicle for hire]] companies such as [[Uber]] and [[Lyft]] allow approved third-party developers to directly order rides from within their apps. This allows the companies to exercise quality control by curating which apps have access to the API, and provides them with an additional revenue stream.<ref>{{Cite web |url=https://www.adexchanger.com/mobile/car-service-apis-everywhere-whats-partner-apps/ |title=Car Service APIs Are Everywhere, But What's In It For Partner Apps? |last=Weissbrot |first=Alison | website=AdExchanger |date=7 July 2016}}</ref>
* Public: The API is available for use by the public. For example, [[Microsoft]] makes the [[Microsoft Windows]] API public, and [[Apple Inc.|Apple]] releases its APIs [[Carbon (API)|Carbon]] and [[Cocoa (API)|Cocoa]], so that software can be written for their [[Computing platform|platforms]].
*<u>Public</u>: The API is available for use by the public. For example, [[Microsoft]] makes the [[Windows API]] public, and [[Apple Inc.|Apple]] releases its API [[Cocoa (API)|Cocoa]], so that software can be written for their [[Computing platform|platforms]]. Not all public APIs are generally accessible by everybody. For example, Internet service providers like Cloudflare or Voxility, use [[RESTful]] APIs to allow customers and resellers access to their infrastructure information, DDoS stats, network performance or dashboard controls.<ref name="Cloudflare">{{Cite web |url=https://api.cloudflare.com/ |title=Cloudflare API v4 Documentation |date=25 February 2020 |website=cloudflare |access-date=27 February 2020}}</ref> Access to such APIs is granted either by “API tokens”, or customer status validations.<ref name="SmashMagazine">{{Cite web |url=https://www.smashingmagazine.com/2018/01/understanding-using-rest-api/ |title=Car Service APIs Are Everywhere, But What's In It For Partner Apps |last=Liew |first=Zell |date=17 January 2018 |website=Smashing Magazine |access-date=27 February 2020}}</ref>


===Public API implications===
===Public API implications===
An important factor when an API becomes public is its ''interface stability''. Changes by a developer to a part of it—for example adding new parameters to a function call—could break compatibility with clients that depend on that API.<ref>{{cite journal|last1=Shi|first1=Lin|last2=Zhong|first2=Hao|last3=Xie|first3=Tao|last4=Li|first4=Mingshu|title=An Empirical Study on Evolution of API Documentation|journal=International Conference on Fundamental Approaches to Software Engineering|date=2011|url=https://www.researchgate.net/profile/Lin_Shi6/publication/225147411_An_Empirical_Study_on_Evolution_of_API_Documentation/links/0fcfd5090639809380000000.pdf|accessdate=22 July 2016|publisher=Springer Berlin Heidelberg}}</ref>
An important factor when an API becomes public is its "interface stability". Changes to the API—for example adding new parameters to a function call—could break compatibility with the clients that depend on that API.<ref name="researchgate.net">{{Cite conference |last1=Shi |first1=Lin |url=https://www.researchgate.net/publication/225147411 |title=An Empirical Study on Evolution of API Documentation |last2=Zhong |first2=Hao |last3=Xie |first3=Tao |last4=Li |first4=Mingshu |date=2011 |conference=International Conference on Fundamental Approaches to Software Engineering |isbn=978-3-642-19810-6 |series=Lecture Notes in Computer Science |volume=6603 |pages=416–431 |doi=10.1007/978-3-642-19811-3_29 |access-date=22 July 2016}}</ref>


When parts of a publicly presented API are subject to change and thus not stable, such parts of a particular API should be explicitly documented as ''unstable''. For example, in the [[Google Guava]] library the parts that are considered unstable, and that might change in a near future, are marked with the [[Java annotation]] <code>@Beta</code>.<ref>{{cite web|url=https://code.google.com/p/guava-libraries/ |title=guava-libraries - Guava: Google Core Libraries for Java 1.6+ - Google Project Hosting |publisher=Code.google.com |date=2014-02-04 |accessdate=2014-02-11}}</ref>
When parts of a publicly presented API are subject to change and thus not stable, such parts of a particular API should be documented explicitly as "unstable". For example, in the [[Google Guava]] library, the parts that are considered unstable, and that might change soon, are marked with the [[Java annotation]] <code>@Beta</code>.<ref>{{GitHub|google/guava|google/guava: Google Core Libraries for Java}}</ref>


A public API can sometimes declare parts of itself as ''[[Deprecation|deprecated]]''. This usually means that such part of an API should be considered candidates for being removed, or modified in a backward incompatible way. Therefore, deprecation allows developers to transition away from parts of the API that will be removed or unsupported in the future.<ref name="OracleDeprecation16">{{cite web|last1=Oracle|title=How and When to Deprecate APIs|url=http://docs.oracle.com/javase/7/docs/technotes/guides/javadoc/deprecation/deprecation.html|website=Java SE Documentation|accessdate=2 August 2016}}</ref>
A public API can sometimes declare parts of itself as ''deprecated'' or rescinded. This usually means that part of the API should be considered a candidate for being removed, or modified in a backward incompatible way. Therefore, these changes allow developers to transition away from parts of the API that will be removed or not supported in the future.<ref name="OracleDeprecation16">{{Cite web |url=http://docs.oracle.com/javase/7/docs/technotes/guides/javadoc/deprecation/deprecation.html |title=How and When to Deprecate APIs |last=Oracle |website=Java SE Documentation |access-date=2 August 2016}}</ref>

Client code may contain innovative or opportunistic usages that were not intended by the API designers. In other words, for a library with a significant user base, when an element becomes part of the public API, it may be used in diverse ways.<ref name="MendezBaudry2013">{{Cite conference |last1=Mendez |first1=Diego |conference=2013 IEEE 13th International Working Conference on Source Code Analysis and Manipulation (SCAM) |last2=Baudry |first2=Benoit |last3=Monperrus |first3=Martin |year=2013 |isbn=978-1-4673-5739-5 |pages=43–52 |title=Empirical evidence of large-scale diversity in API usage of object-oriented software |arxiv=1307.4062 |doi=10.1109/SCAM.2013.6648183 |s2cid=6890739 |url=https://hal.archives-ouvertes.fr/hal-00844753/document}}</ref>
On February 19, 2020, [[Akamai Technologies|Akamai]] published their annual “State of the Internet” report, showcasing the growing trend of cybercriminals targeting public API platforms at financial services worldwide. From December 2017 through November 2019, Akamai witnessed 85.42 billion credential violation attacks. About 20%, or 16.55 billion, were against hostnames defined as API endpoints. Of these, 473.5 million have targeted financial services sector organizations.<ref name="VentureBeat">{{Cite web |url=https://venturebeat.com/2020/02/19/akamai-cybercriminals-are-attacking-apis-at-financial-services-firms/ |title=Akamai: Cybercriminals are attacking APIs at financial services firms |last=Takanashi |first=Dean |date=19 February 2020 |website=Venture Beat |access-date=27 February 2020}}</ref>


==Documentation==
==Documentation==
API documentation describes what services an API offers and how to use those services, aiming to cover everything a client would need to know to use the API.
API documentation describes what services an API offers and how to use those services, aiming to cover everything a client would need to know for practical purposes.
Documentation is crucial for the development and maintenance of applications that use the API.<ref name="DekelHerbsleb9">{{cite journal|last1=Dekel|first1=Uri|last2=Herbsleb|first2=James D.|title=Improving API Documentation Usability with Knowledge Pushing|journal=Institute for Software Research, School of Computer Science|date=May 2009|url=http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.446.4214&rep=rep1&type=pdf|accessdate=22 July 2016|publisher=Carnegie Mellon University}}</ref>
API documentation is traditionally found in documentation files, but can also be found in social media such as blogs, forums, and Q&A websites.<ref name="ParninTreude11">{{cite journal|last1=Parnin|first1=Chris|last2=Treude|first2=Cristoph|title=Measuring API Documentation on the Web|journal=Web2SE|date=May 2011|url=http://chrisparnin.me/pdf/parnin-awebapi.pdf|accessdate=22 July 2016}}</ref>
Traditional documentation files are often presented via a documentation system, such as [[Javadoc]] or [[Pydoc]], that has a consistent appearance and structure.
However, the types of content included in the documentation differs from API to API.<ref name="MaalejRobillard12">{{cite journal|last1=Maalej|first1=Waleed|last2=Robillard|first2=Martin P.|title=Patterns of Knowledge in API Reference Documentation|journal=IEEE TRANSACTIONS ON SOFTWARE ENGINEERING|date=April 2012|url=https://mobis.informatik.uni-hamburg.de/wp-content/uploads/2013/03/TSE-2012-04-0081.R2_Maalej.pdf|accessdate=22 July 2016}}</ref>
To facilitate understanding, API documentation can include description of classes and methods in the API as well as "typical usage scenarios, code snippets, design rationales, performance discussions, and contracts", but implementation details of the API services themselves are usually omitted.
Restrictions and limitations on how the API can be used are also covered by the documentation.
For example, documentation for an API function could note that its parameters cannot be null, or that the function itself is not [[Thread safety|thread safe]].<ref name="MonperrusEichberg11">{{cite journal|last1=Monperrus|first1=Martin|last2=Eichberg|first2=Michael|last3=Tekes|first3=Elif|last4=Mezini|first4=Mira|title=What should developers be aware of? An empirical study on the directives of API documentation|journal=Empirical Software Engineering|date=3 December 2011|volume=17|issue=6|pages=703–737|doi=10.1007/s10664-011-9186-4|url=http://arxiv.org/pdf/1205.6363.pdf|accessdate=22 July 2016}}</ref>
Because API documentation is so comprehensive, it can be difficult for the writers to keep the documentation updated and for the users to read it carefully, potentially resulting in [[Software bug|bugs]].<ref>{{cite journal|last1=Shi|first1=Lin|last2=Zhong|first2=Hao|last3=Xie|first3=Tao|last4=Li|first4=Mingshu|title=An Empirical Study on Evolution of API Documentation|journal=International Conference on Fundamental Approaches to Software Engineering|date=2011|url=https://www.researchgate.net/profile/Lin_Shi6/publication/225147411_An_Empirical_Study_on_Evolution_of_API_Documentation/links/0fcfd5090639809380000000.pdf|accessdate=22 July 2016|publisher=Springer Berlin Heidelberg}}</ref>


Documentation is crucial for the development and maintenance of applications using the API.<ref name="DekelHerbsleb9">{{Cite journal |last1=Dekel |first1=Uri |last2=Herbsleb |first2=James D. |date=May 2009 |title=Improving API Documentation Usability with Knowledge Pushing |journal=Institute for Software Research, School of Computer Science |citeseerx=10.1.1.446.4214}}</ref>
API documentation can be enriched with [[metadata]] information like [[Java annotation]]s. This metadata can be used by the compiler, tools, and by the ''run-time'' environment to implement custom behaviors or custom handling.<ref>{{cite web|url = http://download.oracle.com/javase/1,5.0/docs/guide/language/annotations.html|title = Annotations|accessdate = 2011-09-30|publisher = [[Sun Microsystems]]}}.</ref>
API documentation is traditionally found in documentation files but can also be found in social media such as blogs, forums, and Q&A websites.<ref name="ParninTreude11">{{Cite conference |last1=Parnin |first1=Chris |last2=Treude |first2=Cristoph |title=Measuring API documentation on the web |date=May 2011 |book-title=Proceedings of the 2nd International Workshop on Web 2.0 for Software Engineering |url=https://www.xmedo.com/measuring-api-documentation-web/ |pages=25–30 |doi=10.1145/1984701.1984706 |isbn=9781450305952 |s2cid=17751901 |access-date=22 July 2016}}</ref>


Traditional documentation files are often presented via a documentation system, such as Javadoc or Pydoc, that has a consistent appearance and structure.
==Copyright controversy==
However, the types of content included in the documentation differs from API to API.<ref name="MaalejRobillard12">{{Cite journal |last1=Maalej |first1=Waleed |last2=Robillard |first2=Martin P. |date=September 2012 |title=Patterns of Knowledge in API Reference Documentation |url=https://www.cs.mcgill.ca/~martin/papers/tse2013a.pdf |journal=IEEE Transactions on Software Engineering |volume=39 |issue=9 |pages=1264–1282 |doi=10.1109/TSE.2013.12 |access-date=22 July 2016}}</ref>
{{Main article|Oracle America, Inc. v. Google, Inc.}}
In 2010, [[Oracle Corporation]] sued [[Google]] for having distributed a new implementation of [[Java (programming language)|Java]] embedded in the [[Android (operating system)|Android]] operating system.<ref>{{cite web|url=http://www.drdobbs.com/jvm/232901227 |title=Oracle and the End of Programming As We Know It |publisher=DrDobbs |date=2012-05-01 |accessdate=2012-05-09}}</ref> Google had not acquired any permission to reproduce the Java API, although a similar permission had been given to the [[OpenJDK]] project. Judge [[William Alsup]] ruled in the ''[[Oracle v. Google]]'' case that APIs cannot be [[copyrighted]] in the U.S, and that a victory for Oracle would have widely expanded copyright protection and allowed the copyrighting of simple software commands:


In the interest of clarity, API documentation may include a description of classes and methods in the API as well as "typical usage scenarios, code snippets, design rationales, performance discussions, and contracts", but implementation details of the API services themselves are usually omitted. It can take a number of forms, including instructional documents, tutorials, and reference works. It'll also include a variety of information types, including guides and functionalities.
<blockquote>To accept Oracle's claim would be to allow anyone to copyright one version of code to carry out a system of commands and thereby bar all others from writing their own different versions to carry out all or part of the same commands.<ref>{{cite web|url=http://www.tgdaily.com/business-and-law-features/63756-apis-cant-be-copyrighted-says-judge-in-oracle-case |title=APIs Can't be Copyrighted Says Judge in Oracle Case |publisher=TGDaily |date=2012-06-01 |accessdate=2012-12-06}}</ref><ref>{{cite web

| url = http://www.wired.com/wiredenterprise/wp-content/uploads/2012/05/Judge-Alsup-Ruling-on-Copyrightability-of-APIs.pdf
Restrictions and limitations on how the API can be used are also covered by the documentation. For instance, documentation for an API function could note that its parameters cannot be null, that the function itself is not [[Thread safety|thread safe]].<ref name="MonperrusEichberg11">{{Cite journal |last1=Monperrus |first1=Martin |last2=Eichberg |first2=Michael |last3=Tekes |first3=Elif |last4=Mezini |first4=Mira |date=3 December 2011 |title=What should developers be aware of? An empirical study on the directives of API documentation |journal=Empirical Software Engineering |volume=17 |issue=6 |pages=703–737 |arxiv=1205.6363 |doi=10.1007/s10664-011-9186-4|s2cid=8174618 }}</ref> Because API documentation tends to be comprehensive, it is a challenge for writers to keep the documentation updated and for users to read it carefully, potentially yielding bugs.<ref name="researchgate.net" />

API documentation can be enriched with metadata information like [[Java annotation]]s. This metadata can be used by the compiler, tools, and by the ''run-time'' environment to implement custom behaviors or custom handling.<ref>{{Cite web |url=http://download.oracle.com/javase/1,5.0/docs/guide/language/annotations.html |title=Annotations |publisher=[[Sun Microsystems]] |access-date=2011-09-30 |archive-url=https://web.archive.org/web/20110925021948/http://download.oracle.com/javase/1,5.0/docs/guide/language/annotations.html |archive-date=2011-09-25 |url-status=dead }}.</ref>

It is possible to generate API documentation in a data-driven manner. By observing many programs that use a given API, it is possible to infer the typical usages, as well the required contracts and directives.<ref>{{Cite conference |last1=Bruch |first1=Marcel |conference=2010 7th IEEE Working Conference on Mining Software Repositories (MSR 2010) |last2=Mezini |first2=Mira |last3=Monperrus |first3=Martin |year=2010 |isbn=978-1-4244-6802-7 |pages=141–150 |title=Mining subclassing directives to improve framework reuse |citeseerx=10.1.1.434.15 |doi=10.1109/msr.2010.5463347|s2cid=1026918 }}</ref> Then, templates can be used to generate natural language from the mined data.

==Dispute over copyright protection for APIs==
{{Main|Google LLC v. Oracle America, Inc.}}
In 2010, Oracle Corporation sued Google for having distributed a new implementation of Java embedded in the Android operating system.<ref>{{Cite web |url=http://www.drdobbs.com/jvm/232901227 |title=Oracle and the End of Programming As We Know It |date=2012-05-01 |publisher=DrDobbs |access-date=2012-05-09}}</ref> Google had not acquired any permission to reproduce the Java API, although permission had been given to the similar OpenJDK project. Judge [[William Alsup]] ruled in the ''Oracle v. Google'' case that APIs cannot be [[copyrighted]] in the U.S. and that a victory for Oracle would have widely expanded copyright protection to a "functional set of symbols" and allowed the copyrighting of simple software commands:

{{blockquote|To accept Oracle's claim would be to allow anyone to copyright one version of code to carry out a system of commands and thereby bar all others from writing its different versions to carry out all or part of the same commands.<ref>{{Cite web |url=https://tgdaily.com/business/business-law-features/63756-apis-cant-be-copyrighted-says-judge-in-oracle-case/ |title=APIs Can't be Copyrighted Says Judge in Oracle Case |date=2012-06-01 |publisher=TGDaily |access-date=2012-12-06}}</ref><ref>{{cite web
| url = https://www.wired.com/wiredenterprise/wp-content/uploads/2012/05/Judge-Alsup-Ruling-on-Copyrightability-of-APIs.pdf
| title = Oracle America, Inc. vs. Google Inc.
| title = Oracle America, Inc. vs. Google Inc.
| date = 2012-05-31 | accessdate = 2013-09-22
| date = 2012-05-31 | access-date = 2013-09-22
| publisher = [[Wired (magazine)|Wired]]
| publisher = [[Wired (magazine)|Wired]]
}}</ref></blockquote>
}}</ref>}}

Alsup's ruling was overturned in 2014 on appeal to the [[United States Court of Appeals for the Federal Circuit|Court of Appeals for the Federal Circuit]], though the question of whether such use of APIs constitutes [[fair use]] was left unresolved.<ref>{{Cite web|title=Oracle Am., Inc. v. Google Inc., No. 13-1021, Fed. Cir. 2014|url=https://law.justia.com/cases/federal/appellate-courts/cafc/13-1021/13-1021-2014-05-09.html}}</ref><ref>{{Cite news |last=Rosenblatt, Seth |url=https://www.cnet.com/news/court-sides-with-oracle-over-android-in-java-patent-appeal/ |title=Court sides with Oracle over Android in Java patent appeal |date=May 9, 2014 |work=CNET |access-date=2014-05-10}}</ref>


In 2016, following a two-week trial, a jury determined that Google's reimplementation of the Java API constituted [[fair use]], but Oracle vowed to appeal the decision.<ref>{{Cite web |url=https://arstechnica.com/tech-policy/2016/05/google-wins-trial-against-oracle-as-jury-finds-android-is-fair-use/ |title=Google beats Oracle – Android makes "fair use" of Java APIs |date=2016-05-26 |website=Ars Technica |access-date=2016-07-28}}</ref> Oracle won on its appeal, with the Court of Appeals for the Federal Circuit ruling that Google's use of the APIs did not qualify for fair use.<ref name="bbn march2018">{{Cite web |url=https://www.bloomberg.com/news/articles/2018-03-27/oracle-wins-revival-of-billion-dollar-case-against-google |title=Oracle Wins Revival of Billion-Dollar Case Against Google |last=Decker |first=Susan |date=March 27, 2018 |website=[[Bloomberg Businessweek]] |access-date=March 27, 2018}}</ref> In 2019, Google appealed to the [[Supreme Court of the United States]] over both the copyrightability and fair use rulings, and the Supreme Court granted review.<ref name="ars Jan2019">{{Cite web |url=https://arstechnica.com/tech-policy/2019/01/google-asks-supreme-court-to-overrule-disastrous-ruling-on-api-copyrights/ |title=Google asks Supreme Court to overrule disastrous ruling on API copyrights |last=Lee |first=Timothy |date=January 25, 2019 |website=[[Ars Technica]] |access-date=February 8, 2019}}</ref> Due to the [[COVID-19 pandemic]], the oral hearings in the case were delayed until October 2020.<ref>{{Cite web|last=vkimber|date=2020-09-28|title=Google LLC v. Oracle America, Inc.|url=https://www.law.cornell.edu/supct/cert/18-956|access-date=2021-03-06|website=LII / Legal Information Institute|language=en}}</ref>
In 2014, however, Alsup's ruling was overturned on appeal, though the question of whether such use of APIs constitutes [[fair use]] was left unresolved.<ref>{{cite news | url=http://www.cnet.com/news/court-sides-with-oracle-over-android-in-java-patent-appeal/ | title=Court sides with Oracle over Android in Java patent appeal | work=CNET | date=May 9, 2014 | accessdate=2014-05-10 | author=Rosenblatt, Seth}}</ref>


The case was decided by the Supreme Court in Google's favor.<ref>{{Cite web|date=April 5, 2021|title=Supreme Court of the United States, No. 18–956, GOOGLE LLC, PETITIONER v. ORACLE AMERICA, INC.|url=https://www.supremecourt.gov/opinions/20pdf/18-956_d18f.pdf}}</ref>
In 2016, following a two-week trial, a jury determined that Google's reimplementation of the Java API constituted fair use, but Oracle vowed to appeal the decision.<ref>{{Cite web|url=http://arstechnica.com/tech-policy/2016/05/google-wins-trial-against-oracle-as-jury-finds-android-is-fair-use/|title=Google beats Oracle—Android makes "fair use" of Java APIs|website=Ars Technica|access-date=2016-07-28}}</ref>


==Examples==
== Examples ==
{{See also|Category:Application programming interfaces}}
{{Main category|Application programming interfaces}}


{{Div col||25em}}
{{Div col}}
* [[Advanced SCSI programming interface|ASPI]] for [[SCSI]] device interfacing
* [[Advanced SCSI programming interface|ASPI]] for [[SCSI]] device interfacing
* [[Cocoa (API)|Cocoa]] and [[Carbon (API)|Carbon]] for the [[Macintosh]]
* [[Cocoa (API)|Cocoa]] and [[Carbon (API)|Carbon]] for the [[Macintosh]]
Line 194: Line 243:
* [[OpenCL]] cross-platform API for general-purpose computing for CPUs & GPUs
* [[OpenCL]] cross-platform API for general-purpose computing for CPUs & GPUs
* [[OpenGL]] cross-platform graphics API
* [[OpenGL]] cross-platform graphics API
* [[OpenMP]] API that supports multi-platform shared memory multiprocessing programming in C, C++ and Fortran on many architectures, including Unix and Microsoft Windows platforms.
* [[OpenMP]] API that supports multi-platform shared memory multiprocessing programming in C, C++, and Fortran on many architectures, including Unix and Microsoft Windows platforms.
* [[Server Application Programming Interface]] (SAPI)
* [[Server Application Programming Interface]] (SAPI)
* [[Simple DirectMedia Layer]] (SDL)
* [[Simple DirectMedia Layer]] (SDL)
Line 201: Line 250:
==See also==
==See also==
{{Div col|colwidth=22em}}
{{Div col|colwidth=22em}}
* [[API testing]]
*[[API testing]]
* [[API writer]]
*[[API writer]]
* [[Calling convention]]
*[[Augmented web]]
*[[Calling convention]]
* [[Comparison of application virtual machines]]
* [[Common Object Request Broker Architecture]] CORBA
*[[Common Object Request Broker Architecture]] (CORBA)
*[[Comparison of application virtual machines]]
* [[Document Object Model]] DOM
*[[Document Object Model]] (DOM)
* [[Double-chance function]]
* [[Foreign function interface]]
*[[Double-chance function]]
*[[Foreign function interface]]
* [[Interface (computing)]]
* [[Interface control document]]
*[[Front and back ends]]
*[[Interface (computing)]]
* [[List of 3D graphics APIs]]
*[[Interface control document]]
* [[Name mangling]]
*[[List of 3D graphics APIs]]
* [[Open API]]
*[[Microservices]]
* [[Open Service Interface Definitions]]
*[[Name mangling]]
* [[Platform-enabled website]]
*[[Open API]]
* [[Plug-in (computing)|Plugin]]
*[[Open Service Interface Definitions]]
* [[RAML (software)]]
*[[Parsing]]
* [[Software Development Kit]]
*[[Plug-in (computing)|Plugin]]
* [[Web API]]
* [[XPCOM]]
*[[RAML (software)]]
*[[Software development kit]] (SDK)
*[[Web API]]
*[[Web content vendor]]
*[[XPCOM]]
{{Div col end}}
{{Div col end}}


== References ==
== References ==
{{Reflist|30em}}
{{Reflist}}


==Further reading==
==Further reading==
* {{cite journal |url= http://computationalculture.net/article/objects-of-intense-feeling-the-case-of-the-twitter-api |journal=Computational Culture |year=2013 |author= Taina Bucher |title= Objects of Intense Feeling: The Case of the Twitter API |number=3 |issn=2047-2390 }} argues that "APIs are far from neutral tools" and form a key part of contemporary programming, understood as a fundamental part of culture.
* {{Cite journal |last=Taina Bucher |date=16 November 2013 |title=Objects of Intense Feeling: The Case of the Twitter API |url=http://computationalculture.net/article/objects-of-intense-feeling-the-case-of-the-twitter-api |journal=Computational Culture |issn=2047-2390 |number=3 |ref=none}} Argues that "APIs are far from neutral tools" and form a key part of contemporary programming, understood as a fundamental part of culture.
* [https://www.supremecourt.gov/opinions/20pdf/18-956_d18f.pdf What is an API?] – in the U.S. Supreme [[Court opinion]], [[Google LLC v. Oracle America, Inc.|Google v. Oracle 2021]], pp.&nbsp;3–7 – "For each task, there is [[computer code]]; API (also known as Application Program Interface) is the method for calling that '[[computer code]]' (instruction – like a [[recipe]] – rather than cooking instruction, this is [[Computer|machine]] instruction) to be carry out"
* [http://ondrejka.net/history/2014/02/28/maury.html Maury, Innovation and Change] – Cory Ondrejka \ February 28, 2014 \ " ...proposed a public API to let computers talk to each other". ([https://www.textise.net/showText.aspx?strURL=http://ondrejka.net/history/2014/02/28/maury.html Textise]{{Dead link|date=November 2024 |bot=InternetArchiveBot |fix-attempted=yes }} URL)


==External links==
{{Operating system}}
* [https://go.forrester.com/what-it-means/ep218-google-oracle-api-case/ Forrester : IT industry : API Case : Google v. Oracle] – May 20, 2021 – content format: Audio with text – length 26:41


{{Operating system}}
{{Authority control}}
{{Authority control}}



[[Category:Technical communication]]
[[Category:Application programming interfaces| ]]
[[Category:Application programming interfaces| ]]
[[Category:Technical communication]]

Latest revision as of 10:55, 30 December 2024

For other uses, see API (disambiguation).
"Api.php" redirects here. For the Wikipedia API, see Special:ApiHelp.

An application programming interface (API) is a connection between computers or between computer programs. It is a type of software interface, offering a service to other pieces of software.[1] A document or standard that describes how to build such a connection or interface is called an API specification. A computer system that meets this standard is said to implement or expose an API. The term API may refer either to the specification or to the implementation.

In contrast to a user interface, which connects a computer to a person, an application programming interface connects computers or pieces of software to each other. It is not intended to be used directly by a person (the end user) other than a computer programmer who is incorporating it into software. An API is often made up of different parts which act as tools or services that are available to the programmer. A program or a programmer that uses one of these parts is said to call that portion of the API. The calls that make up the API are also known as subroutines, methods, requests, or endpoints. An API specification defines these calls, meaning that it explains how to use or implement them.

One purpose of APIs is to hide the internal details of how a system works, exposing only those parts a programmer will find useful and keeping them consistent even if the internal details later change. An API may be custom-built for a particular pair of systems, or it may be a shared standard allowing interoperability among many systems.

The term API is often used to refer to web APIs,[2] which allow communication between computers that are joined by the internet. There are also APIs for programming languages, software libraries, computer operating systems, and computer hardware. APIs originated in the 1940s, though the term did not emerge until the 1960s and 70s.

Purpose

[edit]

An API opens a software system to interactions from the outside. It allows two software systems to communicate across a boundary — an interface — using mutually agreed-upon signals.[3] In other words, an API connects software entities together. Unlike a user interface, an API is typically not visible to users. It is an "under the hood" portion of a software system, used for machine-to-machine communication.[4]

A well-designed API exposes only objects or actions needed by software or software developers. It hides details that have no use. This abstraction simplifies programming.[5]

Metaphorically, APIs connect software like interlocking blocks.

Building software using APIs has been compared to using building-block toys, such as Lego bricks. Software services or software libraries are analogous to the bricks; they may be joined together via their APIs, composing a new software product.[6] The process of joining is called integration.[3]

As an example, consider a weather sensor that offers an API. When a certain message is transmitted to the sensor, it will detect the current weather conditions and reply with a weather report. The message that activates the sensor is an API call, and the weather report is an API response.[7] A weather forecasting app might integrate with a number of weather sensor APIs, gathering weather data from throughout a geographical area.

An API is often compared to a contract. It represents an agreement between parties: a service provider who offers the API and the software developers who rely upon it. If the API remains stable, or if it changes only in predictable ways, developers' confidence in the API will increase. This may increase their use of the API.[8]

History of the term

[edit]
A diagram from 1978 proposing the expansion of the idea of the API to become a general programming interface, beyond application programs alone[9]

The term API initially described an interface only for end-user-facing programs, known as application programs. This origin is still reflected in the name "application programming interface." Today, the term is broader, including also utility software and even hardware interfaces.[10]

The idea of the API is much older than the term itself. British computer scientists Maurice Wilkes and David Wheeler worked on a modular software library in the 1940s for EDSAC, an early computer. The subroutines in this library were stored on punched paper tape organized in a filing cabinet. This cabinet also contained what Wilkes and Wheeler called a "library catalog" of notes about each subroutine and how to incorporate it into a program. Today, such a catalog would be called an API (or an API specification or API documentation) because it instructs a programmer on how to use (or "call") each subroutine that the programmer needs.[10]

Wilkes and Wheeler's book The Preparation of Programs for an Electronic Digital Computer contains the first published API specification. Joshua Bloch considers that Wilkes and Wheeler "latently invented" the API, because it is more of a concept that is discovered than invented.[10]

Although the people who coined the term API were implementing software on a Univac 1108, the goal of their API was to make hardware independent programs possible.[11]

The term "application program interface" (without an -ing suffix) is first recorded in a paper called Data structures and techniques for remote computer graphics presented at an AFIPS conference in 1968.[12][10] The authors of this paper use the term to describe the interaction of an application—a graphics program in this case—with the rest of the computer system. A consistent application interface (consisting of Fortran subroutine calls) was intended to free the programmer from dealing with idiosyncrasies of the graphics display device, and to provide hardware independence if the computer or the display were replaced.[11]

The term was introduced to the field of databases by C. J. Date[13] in a 1974 paper called The Relational and Network Approaches: Comparison of the Application Programming Interface.[14] An API became a part of the ANSI/SPARC framework for database management systems. This framework treated the application programming interface separately from other interfaces, such as the query interface. Database professionals in the 1970s observed these different interfaces could be combined; a sufficiently rich application interface could support the other interfaces as well.[9]

This observation led to APIs that supported all types of programming, not just application programming. By 1990, the API was defined simply as "a set of services available to a programmer for performing certain tasks" by technologist Carl Malamud.[15]

Screenshot of Web API documentation written by NASA

The idea of the API was expanded again with the dawn of remote procedure calls and web APIs. As computer networks became common in the 1970s and 80s, programmers wanted to call libraries located not only on their local computers, but on computers located elsewhere. These remote procedure calls were well supported by the Java language in particular. In the 1990s, with the spread of the internet, standards like CORBA, COM, and DCOM competed to become the most common way to expose API services.[16]

Roy Fielding's dissertation Architectural Styles and the Design of Network-based Software Architectures at UC Irvine in 2000 outlined Representational state transfer (REST) and described the idea of a "network-based Application Programming Interface" that Fielding contrasted with traditional "library-based" APIs.[17] XML and JSON web APIs saw widespread commercial adoption beginning in 2000 and continuing as of 2021. The web API is now the most common meaning of the term API.[2]

The Semantic Web proposed by Tim Berners-Lee in 2001 included "semantic APIs" that recast the API as an open, distributed data interface rather than a software behavior interface.[18] Proprietary interfaces and agents became more widespread than open ones, but the idea of the API as a data interface took hold. Because web APIs are widely used to exchange data of all kinds online, API has become a broad term describing much of the communication on the internet.[16] When used in this way, the term API has overlap in meaning with the term communication protocol.

Types

[edit]

Libraries and frameworks

[edit]

The interface to a software library is one type of API. The API describes and prescribes the "expected behavior" (a specification) while the library is an "actual implementation" of this set of rules.

A single API can have multiple implementations (or none, being abstract) in the form of different libraries that share the same programming interface.

The separation of the API from its implementation can allow programs written in one language to use a library written in another. For example, because Scala and Java compile to compatible bytecode, Scala developers can take advantage of any Java API.[19]

API use can vary depending on the type of programming language involved. An API for a procedural language such as Lua could consist primarily of basic routines to execute code, manipulate data or handle errors while an API for an object-oriented language, such as Java, would provide a specification of classes and its class methods.[20][21] Hyrum's law states that "With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody."[22] Meanwhile, several studies show that most applications that use an API tend to use a small part of the API.[23]

Language bindings are also APIs. By mapping the features and capabilities of one language to an interface implemented in another language, a language binding allows a library or service written in one language to be used when developing in another language.[24] Tools such as SWIG and F2PY, a Fortran-to-Python interface generator, facilitate the creation of such interfaces.[25]

An API can also be related to a software framework: a framework can be based on several libraries implementing several APIs, but unlike the normal use of an API, the access to the behavior built into the framework is mediated by extending its content with new classes plugged into the framework itself.

Moreover, the overall program flow of control can be out of the control of the caller and in the framework's hands by inversion of control or a similar mechanism.[26][27]

Operating systems

[edit]

An API can specify the interface between an application and the operating system.[28] POSIX, for example, specifies a set of common APIs that aim to enable an application written for a POSIX conformant operating system to be compiled for another POSIX conformant operating system.

Linux and Berkeley Software Distribution are examples of operating systems that implement the POSIX APIs.[29]

Microsoft has shown a strong commitment to a backward-compatible API, particularly within its Windows API (Win32) library, so older applications may run on newer versions of Windows using an executable-specific setting called "Compatibility Mode".[30]

An API differs from an application binary interface (ABI) in that an API is source code based while an ABI is binary based. For instance, POSIX provides APIs while the Linux Standard Base provides an ABI.[31][32]

Remote APIs

[edit]

Remote APIs allow developers to manipulate remote resources through protocols, specific standards for communication that allow different technologies to work together, regardless of language or platform. For example, the Java Database Connectivity API allows developers to query many different types of databases with the same set of functions, while the Java remote method invocation API uses the Java Remote Method Protocol to allow invocation of functions that operate remotely, but appear local to the developer.[33][34]

Therefore, remote APIs are useful in maintaining the object abstraction in object-oriented programming; a method call, executed locally on a proxy object, invokes the corresponding method on the remote object, using the remoting protocol, and acquires the result to be used locally as a return value.

A modification of the proxy object will also result in a corresponding modification of the remote object.[35]

Web APIs

[edit]
Main article: Web API

Web APIs are the defined interfaces through which interactions happen between an enterprise and applications that use its assets, which also is a Service Level Agreement (SLA) to specify the functional provider and expose the service path or URL for its API users. An API approach is an architectural approach that revolves around providing a program interface to a set of services to different applications serving different types of consumers.[36]

When used in the context of web development, an API is typically defined as a set of specifications, such as Hypertext Transfer Protocol (HTTP) request messages, along with a definition of the structure of response messages, usually in an Extensible Markup Language (XML) or JavaScript Object Notation (JSON) format. An example might be a shipping company API that can be added to an eCommerce-focused website to facilitate ordering shipping services and automatically include current shipping rates, without the site developer having to enter the shipper's rate table into a web database. While "web API" historically has been virtually synonymous with web service, the recent trend (so-called Web 2.0) has been moving away from Simple Object Access Protocol (SOAP) based web services and service-oriented architecture (SOA) towards more direct representational state transfer (REST) style web resources and resource-oriented architecture (ROA).[37] Part of this trend is related to the Semantic Web movement toward Resource Description Framework (RDF), a concept to promote web-based ontology engineering technologies. Web APIs allow the combination of multiple APIs into new applications known as mashups.[38] In the social media space, web APIs have allowed web communities to facilitate sharing content and data between communities and applications. In this way, content that is created in one place dynamically can be posted and updated to multiple locations on the web.[39] For example, Twitter's REST API allows developers to access core Twitter data and the Search API provides methods for developers to interact with Twitter Search and trends data.[40]

Design

[edit]

The design of an API has significant impact on its usage.[5] The principle of information hiding describes the role of programming interfaces as enabling modular programming by hiding the implementation details of the modules so that users of modules need not understand the complexities inside the modules.[41] Thus, the design of an API attempts to provide only the tools a user would expect.[5] The design of programming interfaces represents an important part of software architecture, the organization of a complex piece of software.[42]

Release policies

[edit]

APIs are one of the more common ways technology companies integrate. Those that provide and use APIs are considered as being members of a business ecosystem.[43]

The main policies for releasing an API are:[44]

  • Private: The API is for internal company use only.
  • Partner: Only specific business partners can use the API. For example, vehicle for hire companies such as Uber and Lyft allow approved third-party developers to directly order rides from within their apps. This allows the companies to exercise quality control by curating which apps have access to the API, and provides them with an additional revenue stream.[45]
  • Public: The API is available for use by the public. For example, Microsoft makes the Windows API public, and Apple releases its API Cocoa, so that software can be written for their platforms. Not all public APIs are generally accessible by everybody. For example, Internet service providers like Cloudflare or Voxility, use RESTful APIs to allow customers and resellers access to their infrastructure information, DDoS stats, network performance or dashboard controls.[46] Access to such APIs is granted either by “API tokens”, or customer status validations.[47]

Public API implications

[edit]

An important factor when an API becomes public is its "interface stability". Changes to the API—for example adding new parameters to a function call—could break compatibility with the clients that depend on that API.[48]

When parts of a publicly presented API are subject to change and thus not stable, such parts of a particular API should be documented explicitly as "unstable". For example, in the Google Guava library, the parts that are considered unstable, and that might change soon, are marked with the Java annotation @Beta.[49]

A public API can sometimes declare parts of itself as deprecated or rescinded. This usually means that part of the API should be considered a candidate for being removed, or modified in a backward incompatible way. Therefore, these changes allow developers to transition away from parts of the API that will be removed or not supported in the future.[50]

Client code may contain innovative or opportunistic usages that were not intended by the API designers. In other words, for a library with a significant user base, when an element becomes part of the public API, it may be used in diverse ways.[51] On February 19, 2020, Akamai published their annual “State of the Internet” report, showcasing the growing trend of cybercriminals targeting public API platforms at financial services worldwide. From December 2017 through November 2019, Akamai witnessed 85.42 billion credential violation attacks. About 20%, or 16.55 billion, were against hostnames defined as API endpoints. Of these, 473.5 million have targeted financial services sector organizations.[52]

Documentation

[edit]

API documentation describes what services an API offers and how to use those services, aiming to cover everything a client would need to know for practical purposes.

Documentation is crucial for the development and maintenance of applications using the API.[53] API documentation is traditionally found in documentation files but can also be found in social media such as blogs, forums, and Q&A websites.[54]

Traditional documentation files are often presented via a documentation system, such as Javadoc or Pydoc, that has a consistent appearance and structure. However, the types of content included in the documentation differs from API to API.[55]

In the interest of clarity, API documentation may include a description of classes and methods in the API as well as "typical usage scenarios, code snippets, design rationales, performance discussions, and contracts", but implementation details of the API services themselves are usually omitted. It can take a number of forms, including instructional documents, tutorials, and reference works. It'll also include a variety of information types, including guides and functionalities.

Restrictions and limitations on how the API can be used are also covered by the documentation. For instance, documentation for an API function could note that its parameters cannot be null, that the function itself is not thread safe.[56] Because API documentation tends to be comprehensive, it is a challenge for writers to keep the documentation updated and for users to read it carefully, potentially yielding bugs.[48]

API documentation can be enriched with metadata information like Java annotations. This metadata can be used by the compiler, tools, and by the run-time environment to implement custom behaviors or custom handling.[57]

It is possible to generate API documentation in a data-driven manner. By observing many programs that use a given API, it is possible to infer the typical usages, as well the required contracts and directives.[58] Then, templates can be used to generate natural language from the mined data.

[edit]
Main article: Google LLC v. Oracle America, Inc.

In 2010, Oracle Corporation sued Google for having distributed a new implementation of Java embedded in the Android operating system.[59] Google had not acquired any permission to reproduce the Java API, although permission had been given to the similar OpenJDK project. Judge William Alsup ruled in the Oracle v. Google case that APIs cannot be copyrighted in the U.S. and that a victory for Oracle would have widely expanded copyright protection to a "functional set of symbols" and allowed the copyrighting of simple software commands:

To accept Oracle's claim would be to allow anyone to copyright one version of code to carry out a system of commands and thereby bar all others from writing its different versions to carry out all or part of the same commands.[60][61]

Alsup's ruling was overturned in 2014 on appeal to the Court of Appeals for the Federal Circuit, though the question of whether such use of APIs constitutes fair use was left unresolved.[62][63]

In 2016, following a two-week trial, a jury determined that Google's reimplementation of the Java API constituted fair use, but Oracle vowed to appeal the decision.[64] Oracle won on its appeal, with the Court of Appeals for the Federal Circuit ruling that Google's use of the APIs did not qualify for fair use.[65] In 2019, Google appealed to the Supreme Court of the United States over both the copyrightability and fair use rulings, and the Supreme Court granted review.[66] Due to the COVID-19 pandemic, the oral hearings in the case were delayed until October 2020.[67]

The case was decided by the Supreme Court in Google's favor.[68]

Examples

[edit]
Main category: Application programming interfaces

See also

[edit]

References

[edit]
  1. ^ Reddy, Martin (2011). API Design for C++. Elsevier Science. p. 1. ISBN 9780123850041.
  2. ^ a b Lane, Kin (October 10, 2019). "Intro to APIs: History of APIs". Postman. Retrieved September 18, 2020. When you hear the acronym "API" or its expanded version "Application Programming Interface," it is almost always in reference to our modern approach, in that we use HTTP to provide access to machine readable data in a JSON or XML format, often simply referred to as "web APIs." APIs have been around almost as long as computing, but modern web APIs began taking shape in the early 2000s.
  3. ^ a b Pedro, Bruno (2024). Building an API Product: Design, Implement, Release, and Maintain API Products that Meet User Needs. Packt Publishing. p. 4. ISBN 9781837638536.
  4. ^ Biehl, Matthias (2016). RESTful API Design. API-University Press. p. 10. ISBN 9781514735169.
  5. ^ a b c Clarke, Steven (2004). "Measuring API Usability". Dr. Dobb's. Retrieved 29 July 2016.
  6. ^ Jin, Brenda; Sahni, Saurabh; Shevat, Amir (2018). "Preface". Designing Web APIs: Building APIs That Developers Love. O'Reilly Media. ISBN 9781492026877.
  7. ^ Geewax, JJ (2021). API Design Patterns. Manning. p. 6. ISBN 9781638350330.
  8. ^ Jacobson, Daniel; Brail, Greg; Woods, Dan (2011). APIs: A Strategy Guide. O'Reilly Media. p. 4. ISBN 9781449321642.
  9. ^ a b Database architectures – a feasibility workshop (Report). Washington, DC: U.S. Department of Commerce, National Bureau of Standards. April 1981. pp. 45–47. hdl:2027/mdp.39015077587742. LCCN 81600004. NBS special publication 500-76. Retrieved September 18, 2020.
  10. ^ a b c d Bloch, Joshua (August 8, 2018). A Brief, Opinionated History of the API (Speech). QCon. San Francisco: InfoQ. Retrieved September 18, 2020.
  11. ^ a b Cotton, Ira W.; Greatorex, Frank S. (December 1968). "Data structures and techniques for remote computer graphics". AFIPS '68: Proceedings of the December 9–11, 1968, Fall Joint Computer Conference. AFIPS 1968 Fall Joint Computer Conference. Vol. I. San Francisco, California: Association for Computing Machinery. pp. 533–544. doi:10.1145/1476589.1476661. ISBN 978-1450378994. OCLC 1175621908.
  12. ^ "application program interface". Oxford English Dictionary (Online ed.). Oxford University Press. (Subscription or participating institution membership required.)
  13. ^ Date, C. J. (2019). E. F. Codd and Relational Theory: A Detailed Review and Analysis of Codd's Major Database Writings. Lulu.com. p. 135. ISBN 978-1684705276.
  14. ^ Date, C. J.; Codd, E. F. (January 1975). "The relational and network approaches: Comparison of the application programming interfaces". In Randall Rustin (ed.). Proceedings of 1974 ACM-SIGMOD Workshop on Data Description, Access and Control. SIGMOD Workshop 1974. Vol. 2. Ann Arbor, Michigan: Association for Computing Machinery. pp. 83–113. doi:10.1145/800297.811532. ISBN 978-1450374187. OCLC 1175623233.
  15. ^ Carl, Malamud (1990). Analyzing Novell Networks. Van Nostrand Reinhold. p. 294. ISBN 978-0442003647.
  16. ^ a b Jin, Brenda; Sahni, Saurabh; Shevat, Amir (2018). Designing Web APIs. O'Reilly Media. ISBN 9781492026877.
  17. ^ Fielding, Roy (2000). Architectural Styles and the Design of Network-based Software Architectures (PhD). Retrieved September 18, 2020.
  18. ^ Dotsika, Fefie (August 2010). "Semantic APIs: Scaling up towards the Semantic Web". International Journal of Information Management. 30 (4): 335–342. doi:10.1016/j.ijinfomgt.2009.12.003.
  19. ^ Odersky, Martin; Spoon, Lex; Venners, Bill (10 December 2008). "Combining Scala and Java". www.artima.com. Retrieved 29 July 2016.
  20. ^ de Figueiredo, Luiz Henrique; Ierusalimschy, Roberto; Filho, Waldemar Celes (1994). "The design and implementation of a language for extending applications". Proceedings of XXI Brazilian Seminar on Software and Hardware. pp. 273–284. CiteSeerX 10.1.1.47.5194. S2CID 59833827. Retrieved 29 July 2016.
  21. ^ Sintes, Tony (13 July 2001). "Just what is the Java API anyway?". JavaWorld. Retrieved 2020-07-18.
  22. ^ Winters, Titus; Tom Manshreck; Hyrum Wright, eds. (2020). Software engineering at Google: lessons learned from programming over time. Sebastopol, CA: O'Reilly Media. ISBN 9781492082798. OCLC 1144086840.
  23. ^ Mastrangelo, Luis; Ponzanelli, Luca; Mocci, Andrea; Lanza, Michele; Hauswirth, Matthias; Nystrom, Nathaniel (2015-10-23). "Use at your own risk: the Java unsafe API in the wild". Proceedings of the 2015 ACM SIGPLAN International Conference on Object-Oriented Programming, Systems, Languages, and Applications. New York, New York, U.S.: Association for Computing Machinery. pp. 695–710. doi:10.1145/2814270.2814313. ISBN 978-1-4503-3689-5.
  24. ^ Emery, David. "Standards, APIs, Interfaces and Bindings". Acm.org. Archived from the original on 2015-01-16. Retrieved 2016-08-08.
  25. ^ "F2PY.org". F2PY.org. Retrieved 2011-12-18.
  26. ^ Fowler, Martin. "Inversion Of Control".
  27. ^ Fayad, Mohamed. "Object-Oriented Application Frameworks".
  28. ^ Lewine, Donald A. (1991). POSIX Programmer's Guide. O'Reilly & Associates, Inc. p. 1. ISBN 9780937175736. Retrieved 2 August 2016.
  29. ^ West, Joel; Dedrick, Jason (2001). "Open source standardization: the rise of Linux in the network era" (PDF). Knowledge, Technology & Policy. 14 (2): 88–112. doi:10.1007/PL00022278. Retrieved 2 August 2016.
  30. ^ Microsoft (October 2001). "Support for Windows XP". Microsoft. p. 4. Archived from the original on 2009-09-26.
  31. ^ "LSB Introduction". Linux Foundation. 21 June 2012. Archived from the original on 2015-04-02. Retrieved 2015-03-27.
  32. ^ Stoughton, Nick (April 2005). "Update on Standards" (PDF). USENIX. Retrieved 2009-06-04.
  33. ^ Bierhoff, Kevin (23 April 2009). "API Protocol Compliance in Object-Oriented Software" (PDF). CMU Institute for Software Research. Retrieved 29 July 2016.
  34. ^ Wilson, M. Jeff (10 November 2000). "Get smart with proxies and RMI". JavaWorld. Retrieved 2020-07-18.
  35. ^ Henning, Michi; Vinoski, Steve (1999). Advanced CORBA Programming with C++. Addison-Wesley. ISBN 978-0201379273. Retrieved 16 June 2015.
  36. ^ "API-fication" (PDF). www.hcltech.com. August 2014.
  37. ^ Benslimane, Djamal; Schahram Dustdar; Amit Sheth (2008). "Services Mashups: The New Generation of Web Applications". IEEE Internet Computing. 12 (5). IEEE: 13–15. doi:10.1109/MIC.2008.110. Retrieved 2019-10-01.
  38. ^ Niccolai, James (2008-04-23), "So What Is an Enterprise Mashup, Anyway?", PC World, archived from the original on 2017-10-10, retrieved 2017-09-17
  39. ^ Parr, Ben (23 May 2021). "mobile app development dubai". suffescom. Retrieved 26 July 2016.
  40. ^ "GET trends/place". developer.twitter.com. Retrieved 2020-04-30.
  41. ^ Parnas, D.L. (1972). "On the Criteria To Be Used in Decomposing Systems into Modules" (PDF). Communications of the ACM. 15 (12): 1053–1058. doi:10.1145/361598.361623. S2CID 53856438.
  42. ^ Garlan, David; Shaw, Mary (January 1994). "An Introduction to Software Architecture" (PDF). Advances in Software Engineering and Knowledge Engineering. 1. Retrieved 8 August 2016.
  43. ^ de Ternay, Guerric (Oct 10, 2015). "Business Ecosystem: Creating an Economic Moat". BoostCompanies. Archived from the original on 2016-09-17. Retrieved 2016-02-01.
  44. ^ Boyd, Mark (2014-02-21). "Private, Partner or Public: Which API Strategy Is Best for Business?". ProgrammableWeb. Retrieved 2 August 2016.
  45. ^ Weissbrot, Alison (7 July 2016). "Car Service APIs Are Everywhere, But What's In It For Partner Apps?". AdExchanger.
  46. ^ "Cloudflare API v4 Documentation". cloudflare. 25 February 2020. Retrieved 27 February 2020.
  47. ^ Liew, Zell (17 January 2018). "Car Service APIs Are Everywhere, But What's In It For Partner Apps". Smashing Magazine. Retrieved 27 February 2020.
  48. ^ a b Shi, Lin; Zhong, Hao; Xie, Tao; Li, Mingshu (2011). An Empirical Study on Evolution of API Documentation. International Conference on Fundamental Approaches to Software Engineering. Lecture Notes in Computer Science. Vol. 6603. pp. 416–431. doi:10.1007/978-3-642-19811-3_29. ISBN 978-3-642-19810-6. Retrieved 22 July 2016.
  49. ^ google/guava: Google Core Libraries for Java on GitHub
  50. ^ Oracle. "How and When to Deprecate APIs". Java SE Documentation. Retrieved 2 August 2016.
  51. ^ Mendez, Diego; Baudry, Benoit; Monperrus, Martin (2013). Empirical evidence of large-scale diversity in API usage of object-oriented software. 2013 IEEE 13th International Working Conference on Source Code Analysis and Manipulation (SCAM). pp. 43–52. arXiv:1307.4062. doi:10.1109/SCAM.2013.6648183. ISBN 978-1-4673-5739-5. S2CID 6890739.
  52. ^ Takanashi, Dean (19 February 2020). "Akamai: Cybercriminals are attacking APIs at financial services firms". Venture Beat. Retrieved 27 February 2020.
  53. ^ Dekel, Uri; Herbsleb, James D. (May 2009). "Improving API Documentation Usability with Knowledge Pushing". Institute for Software Research, School of Computer Science. CiteSeerX 10.1.1.446.4214.
  54. ^ Parnin, Chris; Treude, Cristoph (May 2011). "Measuring API documentation on the web". Proceedings of the 2nd International Workshop on Web 2.0 for Software Engineering. pp. 25–30. doi:10.1145/1984701.1984706. ISBN 9781450305952. S2CID 17751901. Retrieved 22 July 2016.
  55. ^ Maalej, Waleed; Robillard, Martin P. (September 2012). "Patterns of Knowledge in API Reference Documentation" (PDF). IEEE Transactions on Software Engineering. 39 (9): 1264–1282. doi:10.1109/TSE.2013.12. Retrieved 22 July 2016.
  56. ^ Monperrus, Martin; Eichberg, Michael; Tekes, Elif; Mezini, Mira (3 December 2011). "What should developers be aware of? An empirical study on the directives of API documentation". Empirical Software Engineering. 17 (6): 703–737. arXiv:1205.6363. doi:10.1007/s10664-011-9186-4. S2CID 8174618.
  57. ^ "Annotations". Sun Microsystems. Archived from the original on 2011-09-25. Retrieved 2011-09-30..
  58. ^ Bruch, Marcel; Mezini, Mira; Monperrus, Martin (2010). Mining subclassing directives to improve framework reuse. 2010 7th IEEE Working Conference on Mining Software Repositories (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.
  59. ^ "Oracle and the End of Programming As We Know It". DrDobbs. 2012-05-01. Retrieved 2012-05-09.
  60. ^ "APIs Can't be Copyrighted Says Judge in Oracle Case". TGDaily. 2012-06-01. Retrieved 2012-12-06.
  61. ^ "Oracle America, Inc. vs. Google Inc" (PDF). Wired. 2012-05-31. Retrieved 2013-09-22.
  62. ^ "Oracle Am., Inc. v. Google Inc., No. 13-1021, Fed. Cir. 2014".
  63. ^ Rosenblatt, Seth (May 9, 2014). "Court sides with Oracle over Android in Java patent appeal". CNET. Retrieved 2014-05-10.
  64. ^ "Google beats Oracle – Android makes "fair use" of Java APIs". Ars Technica. 2016-05-26. Retrieved 2016-07-28.
  65. ^ Decker, Susan (March 27, 2018). "Oracle Wins Revival of Billion-Dollar Case Against Google". Bloomberg Businessweek. Retrieved March 27, 2018.
  66. ^ Lee, Timothy (January 25, 2019). "Google asks Supreme Court to overrule disastrous ruling on API copyrights". Ars Technica. Retrieved February 8, 2019.
  67. ^ vkimber (2020-09-28). "Google LLC v. Oracle America, Inc". LII / Legal Information Institute. Retrieved 2021-03-06.
  68. ^ "Supreme Court of the United States, No. 18–956, GOOGLE LLC, PETITIONER v. ORACLE AMERICA, INC" (PDF). April 5, 2021.

Further reading

[edit]
[edit]
Retrieved from "https://en.wikipedia.org/enwiki/w/index.php?title=API&oldid=1266163965"