API: Difference between revisions

Content deleted Content added
m Reverted edits by 111.248.10.12 (talk) to last version by RichardWeiss
CHUANRU API
Tag: references removed
Line 143:
* 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>
* 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]].
 
===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>
 
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>
 
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>
 
==Documentation==