Talk:API

message: Sunit Pinto is working on API.
Wait a minute, SNMP isn't an API is it? It is a protocol. Don't know much about CORBA, but I wouldn't call DCOM an API.  Robneild 15:53, 16 Feb 2004 (UTC)
thread_title: older entries

message: This article is much too technical for even a computer-oriented person.  It needs to have the introduction completely re-written and the technical details relegated to a lower section.  Of course, I don't have the time...195.176.162.18 (talk) 07:00, 2 September 2008 (UTC)
replies: text: Done. Feedback/edits on the new lead would be great. – FenixFeather (talk)(Contribs) 00:04, 23 July 2016 (UTC)
replies: text: It's all good 107.122.241.112 (talk) 21:12, 21 July 2023 (UTC)
thread_title: Too technical

message: I was thinking about creating Category:Application programming interface, creating a reposity for all the API's that exist in wikipedia, (DirectX, win32, opengl, etc)
* I like this idea Jontce 14:53, 15 November 2005 (UTC)
thread_title: API Category

message: This may sound stupid but what is the difference between an API and a library?
The API is only the interface.  —Preceding unsigned comment added by 80.38.67.99 (talk) 09:06, 16 June 2008 (UTC)
replies: text: In my experience the term 'API' is used interchangeably to mean the library, its interface and the 'contract'. I'm thinking especially about the Java API. --Uncle Ed (talk) 23:25, 7 January 2009 (UTC)
replies: text: That still doesn't make sense.   I think what you guys are really talking about, is the table of symbolic labels (sometimes including expandable macroes) that the symbolic assembler pulls in from disk, processes, and generates executable object code.  Good assemblers let you import other people's tables of labels, and mix them with other people's source code, and more or less bypass the first pass of assembly before generating code.   If that is what you are talking about, the concept of an API is completely illusory.   The execution context really depends on which microprocessor you are working with, in particular, and how the lines of I/O are being dealt with.    For instance, there are microprocessors with extremely limited stacks, and I doubt that a single one of your so-called API's would work with them.  Dexter Nextnumber (talk) 04:09, 21 December 2009 (UTC)
thread_title: Little bit of confusion...

message: I don't think we need all of those links to Example APIs - we are getting dangerously close to link-spam.  Also, the WP:MOS recommends only using external links for references (which ours are not) - or to cover things not adequately described in the article or other Wikipedia articles.  Since we have a good list of internal links to example API's, I move to delete all of the external examples.
:There are two external links in the example list of API's (MediaWiki and Drupal). I suggest we replace them with internal links to the project pages, because external links should be placed under External links section. The external Drupal API link already exists at Drupal, and the external MediaWiki API link could be moved to MediaWiki. --Luen (talk) 09:45, 5 December 2008 (UTC)
replies: text: My feeling on the matter is that if an API is not important enough to have its own page, independent of the product it is an API to, then we probably shouldn't be linking to it.  So I'd just delete these two links, along with everything else in the rightmost column, and the iPhone API. JulesH (talk) 16:19, 6 December 2008 (UTC)
thread_title:  Too many links. 

message: Edcolins
Why would you restore this.  API doesn't redirect to this page it goes to the disambiguation page.  Try it.
jbolden1517Talk 18:26, 5 May 2006 (UTC)
thread_title: API redirects here

message: So how do most people pronounce API?  A P I, or appie?
:I—and every programmer I've worked with—pronounce it "A" and in "day", "P" as in "Pea in a pod", and "I" as in "I love you."  HTH — Frecklefoot | Talk 14:30, 29 August 2006 (UTC)
replies: text: "appie" is too easily confused with other words, many of them emotional.  Programmers hate that ;-)  --Treekids 19:31, 1 October 2007 (UTC)
thread_title: Pronunciation

message: I would like to have a better description of when an API is "open" versus when it is "closed".  The current definition focuses on rights of usage and access to source code, but I think the idea is broader than that.  For example, I think an API is also "open" when it is clearly documented and able to be extended through some defined process.  I also think standardization plays a part in this discussion.  Thoughts? --Mwfnwa 13:00, 5 September 2006 (UTC)
thread_title: Open versus closed

message: I don't believe it is true that an API may only be defined at a source code level.  I don't see any reliable sources that use this definition (a google search that eliminates duplicates and obvious copies of this article turns up nothing useful).  Furthermore, I see plenty of examples of APIs that include details that are not source-code specified, e.g., the Win32 API's reliance on Microsoft's structured exception handling implementation, the MS-DOS API (which specifies register sets that must be initialized to particular values and machine instructions that must be executed to perform a particular function - see, e.g.  for evidence that the term API is used to refer to this), and so on.  The insistance on including the phrase "source code" in the definition, when the next sentence makes it clear that source code is the usual way of defining an API, is simply unsource POV insertion.
:You are right that some vendor APIs include information that would normally be considered part of an ABI.  I suspect that the intent on the vendors part is to produce a single document, rather than have separate API and ABI documents.  This vendor usage ought to be mentioned in the article.  In many ways the Microsoft APIs are heavily tied to Windows and might be called ABIs with an API veneer.  I would also point to the P in API, it is a programming interface; one that gets used when writing software, ie, source code. Derek farn 16:25, 6 August 2007 (UTC)
thread_title:  Source code definition a requirement for being an API? 

message: I note that this version of the article is in many ways superior to the current one.  It's easier to understand, containing as it does a good example of an API described in terms that are relatively easy for a layman to understand (it could have been improved, but as it was it was simply deleted), and the text appears to me to be better written.  Why have we destroyed a perfectly reasonable article? JulesH 14:55, 6 August 2007 (UTC)
replies: text: Ditto! The current article is too technical. And I just saw that we actually have a category for that! Nice! Strawberry Island (talk) 21:56, 13 February 2008 (UTC)
thread_title:  Decreasing quality 

message: Hihi
Working on cleaning up disambiguation pages...the one for API (disambiguation) has well over 500 links to it and more than 99% are meant for this page...I see there's been some discussion in the past about this...we are not saying that the programming language is the ONLY or even BEST definition, but its the one that people are most likely looking for when they type API into the search box.  So I'd ask that you consider allowing me to do the redirect and put the hatnote on this page please?  Thank you for your consideration. Legotech (talk) 17:49, 23 February 2008 (UTC)
thread_title:  Disambiguation 

message: Hello,
I would like to quote what was said about language independent APIs - " Language-independent APIs are written in a way that means they can be called from several programming languages. This is a desired feature for a service-style API which is not bound to a particular process or system and is available as a remote procedure call."
Now what this implies to a relative newcomer like me is that one can have APIs written which can be accessed by programs written in whatever language there is out there. But after reading this - http://en.wikipedia.org/wiki/Remote_procedure_call article on 'Remote Procedure Call' what comes to my mind is that 'remote procedure call' is a mechanism whereby the computer could have one of the sub-routines of the currently executing program to run in parallel on a physically remote computer. And it clearly states in the article that it is a paradigm of distributed computing. So can anyone please explain how does this relate to 'language-independent APIs' ? Some scenarios would be of help here.Aijazbaig1 (talk) 11:38, 15 July 2008 (UTC)
thread_title:  requesting clarification of the term 'Remote Procedure Call' 

message: As a technical writer working on APIs, it seems to me that a bit of grammar help might be a good idea in this article; too often "API" is used to mean one call of many that make up an API and thus too much documentation uses "APIs" where one API (consisting of a multitude of API calls/functions) is meant.
--iFaqeer (talk) 11:31, 17 July 2008 (UTC)
thread_title: APIs

message: This section is almost by definition not about APIs, but how they fit into a larger sofware enterprise. I think it would be better off under Web Services or some such. There are all kinds of other troubles with this article (e.g. I think it is too Web-centric) but the new section, while in good faith, I think belongs elsewhere.
Perhaps put in a separate article and then link to it using main or something?
Best wishes.
SimonTrew (talk) 16:33, 20 April 2009 (UTC)
replies: text: I'm of the opinion that we should probably purge this article of most (if not all) references to web service APIs.  They are fundamentally different, and are better thought of as a protocol than an API, to my mind.  Certainly they don't fit the description of the subject in the lead section. JulesH (talk) 16:54, 20 April 2009 (UTC)
replies: text: I am roughly in agreement; I don't they are totally* irrelevant, but agree most of the time here they are being used to at a very broad description level. The google maps API, for example (I don't know it well) is to my mind an IPI: you submit some XML or SOAP or something to a well know endpoint (an URL of some kind, an http address I think) and it needs to have coords and scale and the other things you expect from maps. Or the google search API probably simpler and better. But "Google" is not an API (it's not suggesting it is here, just using it to try to make a useful distinguishing feature). So yeah most of it is way above the abstraction level of an API. SimonTrew (talk) 17:41, 20 April 2009 (UTC)

text: BTW I wondered whether COM should be thought of as an API, protocol (it's not really a protocol) or whatever, but on balance I think the amount of stuff defined in COM (and Java etc) qualifies as APIs if they are not, by a 100% strict definition, an API of themselves. SimonTrew (talk) 17:44, 20 April 2009 (UTC)
thread_title:  API management (web services) 

message: It's late here so maybe it's just me, but I've read the article and I still don't really understand what an API is, or what actual functions it would be used for, and I'm not a stupid person or someone who has no idea about computing at all. People often use the abbreviation in association with Twitter, and I've heard people talk about API limits etc.
Someone above has suggested it's too technical and I think maybe they're right... I'll come back tomorrow when I've slept and re-read it and see if I can get my head round it any better. In the meantime if anyone has any expertise in making articles like this more accessible to the average Joe or Joanna, I think it would be useful to look at a bit of a rewrite?
91.107.207.207 (talk) 23:27, 24 April 2009 (UTC)
replies: text: I skimmed through the main article, and the whole thing looks like it is only intended for people with modern computers, and not computers from the 1980s.   Are they talking about tables of symbolic labels that the assembler reads in when processing source code, and churning out object code?   Dexter Nextnumber (talk) 04:02, 21 December 2009 (UTC)
thread_title:  I still don't get it 

message: Here's a proposal for a rework of the first paragraph:
In computer science, an application programming interface (API) is a standardized specification for an interface which defines how an application program may request services from the libraries and/or operating systems which provide the services. It may include specifications for routines, data structures, object classes and protocols used to communicate between the requesting software and the software that provides the services. Davemck (talk) 18:48, 20 June 2009 (UTC)
thread_title:  Proposed first paragraph 

message: I wonder who did remove the part on fluent APIs: I'm editing the "advanced explanation" part of this page since a long time in step-by-step way, and that was a part I was going to develop. So why was it removed?  — Preceding unsigned comment added by 62.77.56.17 (talk) 14:39, 25 November 2011 (UTC)
thread_title:  Fluent API description removed 

message: Perhaps mention of the existence of API proxies like Mashery, API Axle (my project), Apigee and 3scale are worth mentioning?  — Preceding unsigned comment added by 81.151.214.141 (talk) 21:27, 23 January 2012 (UTC)
thread_title:  Suggestion of proxy talk 

message: I think there should be a section about the Not Copyrightability of APIs according to the veredict in the "Oracle v. Google" lawsuit () --Aliuken (talk) 14:40, 1 June 2012 (UTC)
thread_title:  Not Copyrightability of APIs 

message: I believe that the sentense "Apple Inc. has shown less concern, breaking compatibility or implementing an API in a slower "emulation mode"; this allows greater freedom in development, at the cost of making older software obsolete" should be removed (or reworded at the very least) as it comes off as being biased towards Microsoft.  Also, no citation is provided to back this statement and I have been unsuccessful in finding such a reference.
Mfd24 (talk) 04:47, 19 October 2012 (UTC)
thread_title:  Reference to Apple 

message: I note that this edit removed the section "Language used".  I get the impression that this was supposed to be vandalism because the next edit, by the same editor, is this.  However, the section seems to missing the point.  Aren't all APIs language-independent?  The section did have no sources.
While we are on the subject of dodgy sections, the "Documentation" section seems to be about code documentation in general, not documentation of APIs.  It mostly comes from this edit by 
Yaris678 (talk) 16:43, 23 October 2012 (UTC)
thread_title:  Dodgy section 

message: This article focuses on what an API is. But I would also like to see additional information - look at this article - http://venturebeat.com/2013/07/31/enterprise-api-programs/  Does anyone have information on what APIs are used for in the industry, how they are used in different companies and institutions, and general statistics about them?  — Preceding unsigned comment added by 192.55.54.41 (talk) 16:20, 31 July 2013 (UTC)
thread_title: Other information about APIs (non-technical)

message: I just added a  hatnote to http://en.wikipedia.org/w/api.php, but it was reverted by JohnBlackburne, so I'd like to open this up for discussion. I don't think it's that unreasonably to assume some people come here looking for our API. See, for instance the traffic stats for the soft redirect api.php. The point of selfrefs is for the rare cases where users are significantly likely to be looking for internal Wikipedia pages, and I think this is such a case; in my opinion, it doesn't make a difference that the link is, technically speaking, external, since it is a Wikipedia link, just not one located in the /wiki section. — PinkAmpers&(Je vous invite à me parler) 01:11, 3 August 2013 (UTC)
replies: text: My thinking on it was twofold. First it's no place for an external link, of any sort. Those usually go in external links, except for narrow exceptions such as official links in 
infoboxes. If it were a link to an actual page it's not an article but a project page and those also should not usually be linked from articles. Those interested in the software WP runs on can use also the links in the sidebar, such as the About Wikipedia link, or the Mediawiki link at the foot of every page, to find out more about the software, including the technical aspects. As for the stats, at 150 a day that's around 2.5% of the 6000 views this page gets a day. Hatnotes are meant for articles the reader is likely to be interested in, which only 2.5% of the views hardly shows, even if it were an article. Finally those who are genuinely interested in reading WP's API documentation should have no trouble finding it themselves.--JohnBlackburnewordsdeeds 01:42, 3 August 2013 (UTC)
thread_title:  Selfref hatnote 

message: Hello fellow Wikipedians,
I have just modified  on Application programming interface. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
*Added archive https://web.archive.org/web/20090926235439/http://www.microsoft.com:80/windowsxp/using/helpandsupport/learnmore/appcompat.mspx to http://www.microsoft.com/windowsxp/using/helpandsupport/learnmore/appcompat.mspx
When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at ).
Cheers.—InternetArchiveBot (Report bug) 16:08, 16 October 2016 (UTC)
replies: text: Checked. --Wikiinger (talk) 23:17, 20 February 2017 (UTC)
thread_title:  External links modified 

message: I think adding a small simple API would aid in understanding.  For example reading the description nothing jumps out at me that an interface is mostly composed of function calls.  What do you think? Daniel.Cardenas (talk) 19:17, 12 December 2019 (UTC)
replies: text: I agree with this. --Marc.2377 (talk) 04:04, 14 December 2019 (UTC)
thread_title:  Example API? 

message: The categorization of APIs into Operating System, Remote APIs and Web APIs is confusing for me.  None of the cited sources in this section clearly draw this delineation.
At a high level, I would argue APIs break down into two major categories, local and remote.  This determination falls depending upon where the client interacts with the interface and the where the interface is enforced.
When an application interacts with local interfaces like a Collections API in a programming language, a hardware API or database driver there is typically enforcement of the interface via code within the client.  This can be through an import that contains the underlying interfaces and fails at compile time; or failure at the interpreter in interpreted languages.  In the cited example of JDBC, the client is interacting with the interface/API in process, even though that interaction results in a call to a potentially remote system, the interaction with the interface occurs locally where the contract is enforced.  The remote call made by the implementation behind the JDBC API may fail due to a bad query, connection information, etc; however the API will still honor its contract given the exceptions specified within it.  Using this argument, I would contend that JDBC is a local API.
When using remote APIs clients are not guaranteed to have the interface enforced in process and the behavior of the API is not strictly defined in a programmatic sense in the client.  The API's contract is enforced exterior to the client's application code and the behaviors specified on the API interface cannot be enforced programmatically in the client.  The client is simply formatting a message in accordance with the programmer's interpretation of information regarding the remote API, passing it over a protocol to a point where the remote API determines adherence to the contract and then (potentially) handles the message.  A clear indicator of a Remote API is that it is agnostic to the language of the client, because the interaction occurs outside of the process used by the client to call the API.  — Preceding unsigned comment added by Kmb385 (talk • contribs) 10:37, 6 December 2020 (UTC)
thread_title:  Web APIs are Remote APIs 

message: I'm a drive-by editor, who hits a page once when I first encounter it and find it lacking, and then briskly moves along, likely to never return. I've learned to accept that some portion of my work is quickly reverted if it's not to the taste of the some other editor who soon ambles along. 
For the record, my attempted lead extension is preserved at: 
* API
I strongly believe that the API is too important to humanity to leave its description entirely in the hands of CS majors. — MaxEnt 18:10, 2 March 2021 (UTC)
replies: text: I wholly agree that the subject is, as you put it, a cultural artifact of immense scope. But the lead now contains statements not sourced or explained in the body, and is probably too long. So I'm afraid much of it won't survive. Jno.skinner (talk) 18:53, 2 March 2021 (UTC)
thread_title:  API as historical and cultural artifact of immense scope 

message: I returned to add the following two passages: 
Concerning the evolution of OS internals:
 
Gradually user devices such as musical instruments with MIDI interfaces, 1980s-era game controllers, and 1990s-era USB peripherals were increasingly abstracted by operating system device drivers, an important API layer internal to the operating system itself.
 
I was there at the time. It was always partly the case that the creatives were running the show, placing a lot of uncomfortable proliferation pressure on the dour greybeards.
Final para, concerning the twin purviews: 
While "application" in some contexts narrowly refers to the end user application, to software developers each layer of the stack is an "application" with respect to the layer beneath, and so the term "API" arises within the industry wherever two layers or components make contact.
— MaxEnt 19:01, 2 March 2021 (UTC)
thread_title: Wrap music

message: So much for a quick in and out. 
The concept of the API is not limited to hardware and code. The Semantic Web as introduced by Tim Berners-Lee in 2001 was a proposal to treat network programming as an API wrapped around the underlying data itself rather than the system's behaviour with a view toward the evolution of intelligent agents as an open innovation entrepreneurship ecosystem. Instead we now have proprietary agents such as Amazon Alexa and Siri which provide natural-language user interfaces rather than programmatic APIs, an entirely different engineering stance toward the human interface boundary.
Maybe at this point I've extended the lead a little too much. 
Feel free to fill you boots with the pruning shears if the spirit moves you. — MaxEnt 19:18, 2 March 2021 (UTC)
thread_title: Data as API

message: Supreme court ruled 6-2 in Googles favor for use of Oracle's Java API. Justice Breyer explained, "The declaring code is, if copyrightable at all, further than are most computer programs from the core of copyright," essentially saying that the code used in APIs are more like dictionaries than novels in terms of copyright protection. 
Along with arguments for Google's favor, we'd like to include some arguments for the opposing side from individuals like Justice Clarence Thomas.
Google approached Oracle to negotiate a license for their API, but ultimately were unsuccessful due to trust issues. Google decided to use Oracle's code anyway even though they could not reach an agreement.  — Preceding unsigned comment added by ThatsGoldJerry (talk • contribs) 19:30, 25 March 2022 (UTC)
thread_title:  Update Dispute over copyright protection for APIs section 

message: I firmly believe the Web API section can be written better. There's a few lines I particularly don't like:
 
As APIs become more accessible every day, I think it's important to make the distinction that this interaction does not need to be between an Enterprise and an application. I plan to make this more generalized, such as web server and application. I also don't think the Service-level agreement is necessary here. I think this is getting too technical for a basic definition introduction. I think the whole paragraph needs to be either removed or reworded to be a lot more inclusive to those without a tech background.
I think this line can be removed or changed, I think many people understand the context since we're in the "Web API" section.
Web APIs have seen a lot of movement in even the past couple of years. I think there is a lot of potential in this section that's not being used. I think people are going to seek out this section a lot more in coming years, so it's important to make it rich and clear.  — Preceding unsigned comment added by Berg2807 (talk • contribs) 19:59, 25 March 2022 (UTC)
thread_title:  Overhaul the Web API section. 

message: In the Design section, we only have a brief description of the general idea of what an applicable API should be like and how it may ease the users' work. However, in terms of design, some detailed information can still be included here. I believe this section can be improved by adding more content about design patterns and principles to make this part more concrete and understandable.--TheaiasR (talk) 08:16, 30 March 2022 (UTC)
thread_title:  Expand Design Section 

message: Hey everyone, I added a security section to this page because I truly believe it's an important topic to have on this page. I added a little bit of content, but I think this is a topic with a lot of potential. I'd love to see someone improve on it.  — Preceding unsigned comment added by Berg2807 (talk • contribs) 06:37, 31 March 2022 (UTC)
thread_title:  Please Expand on the Security section.  

message: "An application programming interface (API) is a way for two or more computer programs to communicate with each other."
nope - an API does not need two or more computers! it's just an interface for an application program. this application need not execute on a different computer. it can be on the same computer, making use of some library on the same computer.
you should fix that. people already quote this erroneous statement e.g. in tutorials in youtube. 90.146.100.207 (talk) 20:34, 9 April 2023 (UTC)
replies: text: it says "two or more computer programs" not "two or more computers" Jno.skinner (talk) 01:13, 10 April 2023 (UTC)
thread_title:  Off To a Bad Start 

message: The redirect API (redirects and miscellaneous) has been listed at redirects for discussion to determine whether its use and function meets the redirect guidelines. Readers of this page are welcome to comment on this redirect at  until a consensus is reached.  Steel1943 (talk) 16:01, 29 November 2023 (UTC)
thread_title:  "[[:API (redirects and miscellaneous)]]" listed at [[Wikipedia:Redirects for discussion|Redirects for discussion]]