Jump to content

Talk:API

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by 182.1.20.138 (talk) at 00:09, 8 August 2020 (→Requested move 3 August 2020: oppose). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Template:Vital article

Former featured articleAPI is a former featured article. Please see the links under Article milestones below for its original nomination page (for older articles, check the nomination archive) and why it was removed.
Article milestones
DateProcessResult
January 19, 2004Refreshing brilliant proseKept
March 6, 2005Featured article reviewDemoted
Current status: Former featured article

older entries

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)

The definition at the top of this document is too inclusive, with the result that protocols would be considered APIs. The common use of the term is for a collection of classes or functions. CORBA is many things (protocol, language mappings, type system...) and it happens to include an API as well - the ORB API. But most people would not call CORBA an API. At most, it is a language for expressing APIs. Yaronf 23:31, Feb 18, 2004 (UTC)


Your definition of API's is way too inclusive. The API is the programming language interface provided to users, in that programming language. This is different than protocols, which usually represent the "wire" format of the actual communication. This might be the may web interfaces, IIOP in CORBA, or the conventions used in a socket call. Representing these in XML and ontologies are the next evoloution of Protocols - but not of API's. I contend that API's are to be minimized as they create basically the next N squared problem in that to get them implemented in every language, you have a very uphill battle, let alone making changes. Protocols, on the other hand, can evolve and you let the languages find their way to create the protocol. The reference to ontologies would fit with the Protocols, but not with the API.s

Too technical

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)[reply]

Done. Feedback/edits on the new lead would be great. – FenixFeather (talk)(Contribs) 00:04, 23 July 2016 (UTC)[reply]

API Category

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)[reply]
  • I couldn't find a better section and I'm new to commenting, so I've included my comment here. Let me apologize in advance if my thoughts are not in the proper area. I wanted to comment on the over-explanation of ABI's in this article. Someone needs to go back and clean that up. If ABI plays an important role in explanation, then so be it, but it needs to just have a link to another wikipedia section explaining ABI. For someone who does not understand all the basic concepts behind API or ABI, the additional information of ABI here simply threw me off. —Preceding unsigned comment added by Chrisban35 (talk • contribs) 13:52, 29 March 2009 (UTC)[reply]

Little bit of confusion...

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)[reply]

Simply, an API is a contract to adhere to while a library is an implementation of that contract.

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)[reply]
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)[reply]

Bold text== Framework,API,Library,Protocol ==

Dear All,

Documentation in particular could use further citation than what currently exists, and, if possible, a less technical definition. Or for that matter, simply a more layman's description of what is going on in the code.


Dear All 

       I think it is gona be a big miss understanding here, as a

programmer in the first place and Systems Analyst, i can tell that we are talking about this Pyramid: 

                 -----------Program-----------
              -------------Libraries-------------
          -------------------APIs-------------------
   -----------------------Framework-----------------------

Operating System Layer--->Protocols---> Operating System

the programmers usually make their own libraries using calls to APIs which usually be a part of a particular framework which must be based in a particular operatin system, and the operating system uses a protocol to manage the communication with another operating system.

as an example, if we are talking about :

The Program------------------------------

Programmer Made Library to manage what ever tasks---- .NET APIs (System.Windows, System.Windows.Form...etc)

.NET Framework-----------------------------

WINDOWS XP------------------------------

Best Regards Hossam Abbas

That pyramid is deceptive. It is possible (for example) for a single API to be spread across multiple libraries - or for one library to implement multiple API's. An API is a specification for an interface - typically between a program and a library - but possibly between two libraries - or between a 'plugin' and a program. An API is more like a piece of documentation than an actual library. A single API can apply to multiple implementations - and hence to multiple libraries. I can write an OpenGL application that links both to (say) nVidia's OpenGL implementation and the Mesa OpenGL implementation. Two implementations of the same API. The reason we need the concept of an API is precisely because the word library doesn't work.

SteveBaker 14:41, 2 February 2006 (UTC)[reply]

Too many links.

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)[reply]
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)[reply]

This article needs to get it's Featured Article status back again. SteveBaker 22:21, 31 March 2006 (UTC)[reply]

Application Programming Interface OR Application Program Interface

Just to check; technically is it an Application Programming Interface or is it an Application Program Interface? I know this is very picky, but an Encyclopedia should get it right. (please don't flame me). Thanks --Skoorb 17:26, 1 April 2006 (UTC)[reply]

I believe it is Application Program Interface since the interface remains between the application and the library long after the act of Programming has been completed. One might even (theoretically) define the API after all of the programming has been completed - for example when you decide that a part of an existing application could be split off and made into a library if only you wrote down a specification for the API. However, it's a small thing - and since this is one of those informal terms that has gradually taken hold, it's perfectly possible that some users take one meaning and others the reverse position. SteveBaker 17:34, 1 April 2006 (UTC)[reply]

I have seen API defined as an Abstract Programming Interface. ChopMonkey 15:08, 2 October 2006 (UTC)[reply]

Another term which is often used and makes IMHO most sense is 'Application Programmer Interface', as it is an interface for the developer to write a new application.

I agree with the comment above, 'Application Programmer's Interface' is also used often. 88.255.168.161 08:17, 26 June 2007 (UTC)[reply]

"An API is to the programmer what a GUI is to the end-user. The 'P' in API stands for "Programmer", not "Program", to highlight the fact that APIs are used by programmers, who are humans." Maybe there should be a reference to the fact, that API has different decronyms which lead to different interpretations. 85Pando (talk) 11:34, 7 May 2010 (UTC)[reply]

IETF RFCs, IEEE, and many other highly reputable sources break it out as "Application Programmer Interface". This is the break-out that is taught in the University of Maryland where I received my graduate degree. The break-out given in this article is a mistake. - --User:aja12aja 21:13, 26 December 2013 (UTC)[reply]

API redirects here

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)[reply]

API should redirect to disambig not here. It's totally unfair to other disciplines to monopolize just because it's common in our field. --Treekids 19:25, 1 October 2007 (UTC)[reply]

Pronunciation

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)[reply]
"appie" is too easily confused with other words, many of them emotional. Programmers hate that ;-) --Treekids 19:31, 1 October 2007 (UTC)[reply]

Open versus closed

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)[reply]

I agree that this aspect needs work. the emphasis is on the financial cost of access and application. how about addressing the issue question of who gets access? as i understand it, an open api (or any open technology) is equally open to all comers.

in other words, if make my technology available free of charge to my friends, charge others for it, and do not make it available at all to those i regard as potential competitors, my technology (api or not) is not open. (i seem to recall that one of the standards bodies makes this an important part of their definition of "open standard." ie, not whether there is a charge, but whether or not the same thing is available to anyone willing to pay and at the same price.) - ef


Multi-language API's

Shouldn't we have an example of a language-independent API, such as DOM?:

The Document Object Model is a platform- and language-neutral interface that will allow programs and scripts to dynamically access and update the content, structure and style of documents. (From http://www.w3.org/DOM/)

Please, take not that there is also at least another internation meaning of "API": Active Pharmaceutical Ingredient. I don't know how to do, but I think that Wik should mention it. Ciao

Source code definition a requirement for being an API?

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. [1] 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)[reply]

I'm not going to remove it again yet, to give those who favour its inclusion a chance to justify it. But I think they'll have a hard job. JulesH 14:49, 6 August 2007 (UTC)[reply]

When source code is not provided, there is a real issue here that the API definitions are almost always at best ambiguous and underspecified. Simply, the black box mapping is never specified in practice in these cases, nor is the mapping unambiguously defined (basically in contrast to when the API is accompanied by source code and an open source build tool chain -- http://cm.bell-labs.com/who/ken/trust.html ). Hozelda (talk) 00:27, 30 January 2009 (UTC)[reply]

If you are not giving tools to a programmer that can directly interface with a component/library/remote system behavior, without introducing intermediate abstractions, you have something other than an API. You need some programmatic interface (API!) for programmers to use, and the interface should be a direct one, not a general purpose "here's a socket, send packages in this sequence with this structure". The latter is a transport protocol. If you have a RESTful web service speaking JSON, you only have an API if your platform can abstract away the protocol specifics. Otherwise, it's just a web service call you're making, no doubt using some other intermediate API to help you (sockets, HTTP, etc). 72.142.11.38 (talk) 15:24, 13 June 2017 (UTC)[reply]

Decreasing quality

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)[reply]

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)[reply]


Wow, the word "inculcate" is used in first paragraph of the introduction! Can't someone find a way to describe whatever is trying to be said there using simpler words? I know this isn't on the simplified English version of Wikipedia, but, come on, I am a native English speaker, I had to look the word up, and I STILL don't know what they were trying to say there. Most people who are viewing this article are NOT going to be a combination of a college English major and programmer.Mmortal03 (talk) 10:48, 25 February 2008 (UTC)[reply]



An earlier version of this article made it clear that the [original] purpose of an API was to allow an application coded in a standard language and using a standard API [e.g. POSIX] the ability to easily port to a different platform that provided the same language and API(s). At the same time that the term API originated (early 1990s), ABIs were being explored [e.g. Java] as another solution to program portability. The acronym has [been bastardized to] come to mean "any interface" and "any method signature in an interface" which I regard as a useless development diluting a meaning-rich term. It's now difficult to impossible to describe the evolution of portability and to speak about lessons from the past. Disappointing. Tangential to the discussion about removal of meaning/nuance from the language, as a native English speaker (who spent much of his childhood with a book in one hand and a dictionary in the other), I'd be ashamed to admit that I didn't wish to take a minute to expand my vocabulary. I recommend wiktionary.org/wiki/<word> – --Koan911 (talk) 03:05, 3 April 2017 (UTC)[reply]

Disambiguation

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)[reply]

requesting clarification of the term 'Remote Procedure Call'

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)[reply]

APIs

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)[reply]

API management (web services)

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)[reply]

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)[reply]
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)[reply]
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)[reply]

I've added a short section describing Web APIs (which could use a bit of editing & additional references) because this phrase is now in common parlance, whatever the technical accuracy of describing these services as APIs. Danja (talk) 07:50, 20 July 2009 (UTC)[reply]

API did not originally refer to web API's simply because they didn't *exist* at the time. It's absurd to get pedantic and nitpick about the meaning of terms which were never intended to have rigid definitions in the first place. Google themselves refer to their own Maps services as an API -- are we going to say that the guys at Google don't understand computer terminology? Limbo socrates (talk) 22:22, 22 October 2009 (UTC)[reply]

An API is just an interface. Web services define formal contracts (WSDL for SOAP, REST is mean to be self-describing, though Open API is also present). That addresses the I part in API. With COM, we see something similar; the I part is dealt with. Focus on the Application Programming part. WSDL allows you to generate client stubs (and server skeletons). Most IDL based schemes work this way, so RPC, CORBA,DCOM and SOAP/WSDL are in that category. The generated code is essentially your API. Without code, you just have protocols. Consider, every DB vendor has a protocol that their database drivers uses to talk to the database. If we use that protocol directly, (if we could), are we using an API? No. Obviously not. What of RESTful web services? The interface is defined by HTTP + the resource format. One may even have an OpenAPI description. If your resource format happens to be JSON, you can use the web service without generated client code on a JavaScript platform; all operations have been standardized (GET, PUT, etc), and so the API *is* in large part the HTTP client your platform supports. Or so it is argued. This does make for clumsy APIs, though, which simply defer to HTTP (protocol) semantics. If your subject matter is complex, you may be tempted to write a client-api which shields all the HTTP-ness of the "web api" away from the programmer. 72.142.11.38 (talk) 15:45, 13 June 2017 (UTC)[reply]

I still don't get it

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)[reply]

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)[reply]

Proposed first paragraph

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)[reply]

The API - protocol relationship

The article's discussion of how APIs and protocols relate to each other seems confusing and incomplete. Statements like "An API can also be an implementation of a protocol", "API provides a library to be used directly", and "APIs are specific to a given technology" are unclear, most likely inaccurate, possibly even incorrect. In my opinion, it is certain that:

1) There is a relationship between APIs and protocols

2) This relationship is important for describing

2.1) the differences between local (in-process)and remote APIs

2.2) the differences between APIs giving access to the same service or functionality from different programming languages and environments

2.3) the differences between SOAP- and REST-based Web APIs (providing access to identical functionality)

2.4) the precise role of the language bindings

2.5) abstract interfaces which exist only in form of documentation, without explicit or automatically generated language bindings

I don't think this article contains a satisfactory discussion of the above points.

Part of the problem was discussed here before and it has to do with the "wide" versus "narrow" definition of APIs. The "wide" definition includes any interface that provides programmatic access to a service or functionality. The "narrow" definition considers APIs strict in the context of a given programming language, environment or technology. The article starts out by giving the "wide" definition " ...particular set of rules and specifications that software programs can follow to communicate with each other" but the section about protocols treats the subject by taking the "narrow" point of view. This inconsistency is very confusing.

I have a relatively good understanding of the subject, but I'm new to Wikipedia and I don't have references so I'm a bit hesitant to edit the article. Is anybody interested in working with me to clarify the topic?

--Fmihaly (talk) 23:39, 29 June 2011 (UTC)Ferenc[reply]

Thank you for your suggestion, I think it will improve the Protocols secion. Feel free to make those changes by yourself. Wikipedia is a wiki, so anyone can edit almost any article by simply following the edit this page link at the top.
The Wikipedia community encourages you to be bold in updating pages. Don't worry too much about making honest mistakes—they're likely to be found and corrected quickly, and other editors can follow the page history to watch changes and add their opinions. If you're not sure how editing works, check out how to edit a page, or use the sandbox to try out your editing skills. New contributors are always welcome. Diego Moya (talk) 09:56, 30 June 2011 (UTC)[reply]

Fluent API description removed

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)[reply]

Suggestion of proxy talk

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)[reply]

Not Copyrightability of APIs

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

Reference to Apple

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)[reply]

Dodgy section

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 62.77.56.17 (talk · contribs · count · logs)

Yaris678 (talk) 16:43, 23 October 2012 (UTC)[reply]

Other information about APIs (non-technical)

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)[reply]

Selfref hatnote

I just added a {{selfref}} 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)[reply]

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)[reply]

Hello fellow Wikipedians,

I have just modified one external link 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:

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

checkY An editor has reviewed this edit and fixed any errors that were found.

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 16:08, 16 October 2016 (UTC)[reply]

Checked. --Wikiinger (talk) 23:17, 20 February 2017 (UTC)[reply]

Hello Admin,

I was reading the content on Application programming interface on this page and i noted a link which is broken. It is a pdf file with anchor text "On the Criteria To Be Used in Decomposing Systems into Modules". I managed to find the originial pdf file.Here is the link of that file. https://web.archive.org/web/20180108050207/http://www.cs.umd.edu/class/spring2003/cmsc838p/Design/criteria.pdf . I would request you to link the pdf to this link so that readers will be able to reader the original pdf file.Apart from that i also noticed that this website techved.com has lot of contribution to Application programming interface. Would like to see information from this website.

Example API?

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)[reply]

I agree with this. --Marc.2377 (talk) 04:04, 14 December 2019 (UTC)[reply]

Does anyone else think that the history of API misses the forest for the trees

I've been programming since 1971, and the current so called "Web API" would not be considered to be an API even up to 2000. Apparently, somebody published a paper that unilaterally redefined the term, and then maybe 10 or twenty years later it pops up on a search because the older stuff is pre-internet and voila, the term API is completely redefined. The history of API as it exists in this article reeks of shoddy scholarship. If the industry for some strange reason sees the need to co-opt a term that doesn't really fit the concept of a set of web endpoints to expose a set of coordinated services [which is what the current term means], then so be it, but the Wikipedia article should at least set the record strait that the current term is not at all what was understood by the originators of the term. Also, AFAICT, there is no reference listed prior to 2000, that in itself should be a giant tip off that the scholarship of this article sucks. I can recall the term being in use at least by 1989, and I suspect it is much older. Just a quick and dirty search of magazines on google books returns references in 1989 used as if it were already a well known and understood term. Again, the scholarship of this article sucks. — Preceding unsigned comment added by Gkochanowsky (talk • contribs) 18:10, 2 March 2020 (UTC)[reply]

Requested move 3 August 2020

Application programming interface → API – This strikes me as a case where the more commonly recognizable name for the subject is its acronym. The relevant naming convention here is WP:NCACRO, which states: Acronyms should be used in a page name if the subject is known primarily by its abbreviation and that abbreviation is primarily associated with the subject. It also states: In general, if readers somewhat familiar with the subject are likely to only recognise the name by its acronym, then the acronym should be used as a title. This is the case with APIs. Many of the sources cited within this article introduce APIs with the acronym first before spelling it out, e.g. [3][4][5]. See also Google Ngrams. API currently redirects here, so spelling it out is not needed for disambiguation either. I argue that the acronym "API" would be the title most recognizable for the subject, for both lay readers and experts. Mz7 (talk) 05:56, 3 August 2020 (UTC)[reply]

  • Oppose because many language issues regarding the term. In Indonesian and Malay languages, "API" means "fire", so when searching about "API", Primary topic then redirects to the fire instead what naming intend. Renaming Application programming interface to just API would be confusing for people speaking other languages, notably Indonesian and Malay. 36.76.227.254 (talk) 06:20, 3 August 2020 (UTC)[reply]
  • Oppose "API" means fire in Malay languages so is not necessary to changed to just acronym. 114.125.253.37 (talk) 06:37, 3 August 2020 (UTC)[reply]
    I honestly don't see why the Indonesian/Malay language term is relevant at all. API already redirects to this article. -- Netoholic @ 10:38, 3 August 2020 (UTC)[reply]
  • Oppose per WP:ACRONYMTITLE because in this case, most sources do have to explain the acronym (especially when targeted at readers that are not specifically-versed in the specialty jargon). Specifically within computer topics, we have a long history of expanding such acronyms out in titles/lead sentences (graphics processing unit, graphical user interface, Peripheral Component Interconnect). Expanded acronyms like this also provide WP:NATURALDIS. --Netoholic @ 10:38, 3 August 2020 (UTC)[reply]
    In this particular case, the text of ACRONYMTITLE more strongly favors using the acronym, more akin to USB or HDMI than the examples you cited, where readers might plausibly use the long name in everyday speech (there are a few other computing-related topics I feel are also counter to ACRONYMTITLE, e.g. Cascading Style Sheets). I have no problem with spelling out the acronym in the lead sentence of the article, but in this case it seems quite probable that readers somewhat familiar with the subject are likely to only recognise the name by its acronym. Mz7 (talk) 13:46, 3 August 2020 (UTC)[reply]
    The difference is that USB and HDMI are consumer-level terms of the sort a broad range of people come across quite frequently and are part of general knowledge - such as when purchasing a TV. "API" is quite the opposite - a term used only by programmers and developers primarily - specialist knowledge. -- Netoholic @ 14:00, 3 August 2020 (UTC)[reply]
  • Support, I agree that this is one of the cases where the expanded title is not descriptive to those that don't know the subject, and it is also much less recognizable. I find this to be different from graphical user interface and similar subjects where the expanded title is descriptive and recognizable. We do however not have that many unexpanded computer-related titles here apart from HTML, XML, PDF and a handful of others. – Thjarkur (talk) 10:43, 3 August 2020 (UTC)[reply]
  • Support per nom and Thjarkur. Calidum 15:01, 3 August 2020 (UTC)[reply]
  • Strong support per nom, and WP:COMMONNAME.--Ortizesp (talk) 23:21, 3 August 2020 (UTC)[reply]
  • Support per WP:COMMONNAME (and personal experience). As a programmer, I've never once heard anyone call an API an "Application programming interface" when referring to it (or even when explaining it to others in a conversation). If you google "Application programming interface", all of the first page hits use "API" in the title and use it as the main term in the article, with the longer title used as an expansion of the acronym only. - Whisperjanes (talk) 18:53, 4 August 2020 (UTC)[reply]
  • Oppose because in my opinion, API means fire in Malay and Indonesian Ianguage and it should be remain like this title. 182.1.20.138 (talk) 00:09, 8 August 2020 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:API&oldid=971749162"