Content deleted Content added
mNo edit summary |
TurboSuperA+ (talk | contribs) unsourced addition, possibly LLM-generated |
||
| (905 intermediate revisions by more than 100 users not shown) | |||
Line 1:
{{short description|
{{
{{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 name=":0">{{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 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]]<ref name=":0" /> 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.
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 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 ==
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>
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>
[[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/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 |url-access=subscription }}</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 |url-access=subscription }}</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]].
==
===Libraries and frameworks===
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 [[Java (programming language)|Java]] compile to compatible [[bytecode]], Scala developers can take advantage of any Java API.<ref name="OderskySpoonVenners8">{{
API use can vary depending on the type of programming language involved.
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
[[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">{{
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.
Moreover, the overall program flow of control can be out of the control of the caller and in the framework's hands
|first = Martin
|last = Fowler
Line 44 ⟶ 76:
}}
</ref>
===Operating systems===
An API can specify the interface between an application and the [[operating system]].<ref name="Oreilly91">{{
[[Linux]] and [[Berkeley Software Distribution]] are examples of operating systems that implement the POSIX APIs.<ref name="WestDedrick16">{{
{{cite web
|author=
|url=http://www.microsoft.com/windowsxp/using/helpandsupport/learnmore/appcompat.mspx
|title=Support for Windows XP
|publisher=Microsoft
|page=4
|date=October 2001
|url-status=dead
|
|
}}</ref> How much Microsoft developers' access to the company's operating systems' internal APIs is an advantage is unclear. Richard A. Shaffer of ''Technologic Computer Letter'' in 1987 compared the situation to a baseball game in which "Microsoft owns all the bats and the field",<ref name="barney19871102">{{Cite magazine |last=Barney |first=Douglas |date=1987-11-02 |title=Balancing on the high wire of Microsoft's success |url=https://books.google.com/books?id=mUSIMiurpfYC&pg=PP81 |access-date=2025-06-08 |magazine=Computerworld |page=SR15 |volume=XXI |issue=44}}</ref> but [[Ed Esber]] of [[Ashton-Tate]] said in an interview that year that [[Bill Gates]] told him that his developers sometimes had to rewrite software based on early APIs. Gates noted in the interview that Microsoft's [[Apple Macintosh]] applications were more successful than those for MS-DOS, because his company did not have to also devote resources to [[Classic Mac OS|Mac OS]].<ref name="computerworld19871102interview">{{Cite interview |last=Gates |first=Bill |interviewer=Paul Gillin |title=The great software debate |last2=Manzi |first2=Jim |last3=Esber |first3=Ed |url=https://books.google.com/books?id=mUSIMiurpfYC&pg=PP73 |access-date=2025-06-08 |work=Computerworld |issue=44 |date=1987-11-02 |page=SR7 |volume=XXI}}</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|
Line 68 ⟶ 100:
title=LSB Introduction|
publisher=Linux Foundation|date=21 June 2012|
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|
last=Stoughton|
Line 74 ⟶ 109:
title=Update on Standards|
publisher=[[USENIX]]|date=April 2005|
===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.
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">{{
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
|
|
|
|
|year = 1999
|url = https://archive.org/details/advancedcorbapro00henn
|title = Advanced CORBA Programming with C++
|publisher = [[Addison-Wesley]]
|
|url-access = registration
|access-date = 16 June 2015
}}</ref>
===Web APIs===
{{Main|Web API}}
Web
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
|first = Djamal
|
|
|
|title = Services Mashups: The New Generation of Web Applications
|doi = 10.1109/MIC.2008.110
|url = https://www.computer.org/csdl/magazine/ic/2008/05/mic2008050013/13rRUytWFdu
|journal = IEEE Internet Computing
|
|
|publisher = IEEE
|pages = 13–15
|year = 2008
|access-date = 2019-10-01
|url-access= subscription
}}</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
|last
|title = So What Is an Enterprise Mashup, Anyway?
|url
|work
|date
|access-date = 2017-09-17
|archive-date = 2017-10-10
|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="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/|website=Mashable|date=21 May 2009|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==
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">{{
==Release policies==
APIs are one of the more common ways technology companies integrate
last=de Ternay|
first=Guerric|
Line 150 ⟶ 177:
website=BoostCompanies|
date=Oct 10, 2015|
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">{{
*<u>Private</u>: The API is for internal company use only.
*<u>Partner</u>: Only specific business partners can use the API. For example, [[
*<u>Public</u>: The API is available for use by the public. For example, [[Microsoft]] makes the [[
===Public API implications===
An important factor when an API becomes public is its "interface stability". Changes
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
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
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">{{
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==
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.<ref name="DekelHerbsleb9">{{
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">{{
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">{{
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 safety|thread safe]]
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>{{
It is possible to generate API documentation in a data-driven manner. By observing
==Dispute over copyright protection for APIs==
{{Main|
In 2010, Oracle Corporation sued Google for having distributed a new implementation of Java embedded in the Android operating system.<ref>{{
{{
| 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.
| date = 2012-05-31 |
| publisher = [[Wired (magazine)|Wired]]
}}</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
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>
== Examples ==
Line 213 ⟶ 245:
* [[OpenCL]] cross-platform API for general-purpose computing for CPUs & GPUs
* [[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.
* [[Server
* [[Simple DirectMedia Layer]] (SDL)
{{Div col end}}
Line 220 ⟶ 252:
==See also==
{{Div col|colwidth=22em}}
*
*
*
*[[Calling convention]]
*
*[[Comparison of application virtual machines]]
*[[Document Object Model]] (DOM)
*
*
*[[Front and back ends]]
*
*
*[[List of 3D graphics APIs]]
*
*
*
*
*[[Parsing]]
*
*
*
*
*
*[[XPCOM]]
{{Div col end}}
Line 249 ⟶ 282:
==Further reading==
* {{
* [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. 3–7 – "For each task, there is [[source code|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://web.archive.org/web/20211018221509/https://www.textise.net/showText.aspx?strURL=http://ondrejka.net/history/2014/02/28/maury.html Textise] URL)
==External links==
* [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}}
[[Category:Application programming interfaces| ]]
[[Category:Technical communication]]
| |||