एपीआई: Difference between revisions

From Vigyanwiki
Line 194: Line 194:
2010 में, ओरेकल कॉर्पोरेशन ने एंड्रॉयड ऑपरेटिंग सिस्टम में अंतर्निहित किए गए जावा के एक नए कार्यान्वयन को वितरित करने के लिए गूगल पर मुकदमा दायर किया।<ref>{{Cite web |url=http://www.drdobbs.com/jvm/232901227 |title=ओरेकल और प्रोग्रामिंग का अंत जैसा हम जानते हैं|date=2012-05-01 |publisher=DrDobbs |access-date=2012-05-09}}</ref> गूगल ने जावा एपीआई को पुन: उत्पन्न करने के लिए कोई अनुमति प्राप्त नहीं की थी, हालाँकि समान ओपेन जेडीके (OpenJDK) प्रोजेक्ट को अनुमति दी गई थी। गूगल ने अपने एपीआई के लिए एक लाइसेंस के लिए बातचीत करने के लिए ओरेकल से संपर्क किया था, लेकिन भरोसे के मुद्दों के कारण इसे ठुकरा दिया गया था। असहमति के बावजूद, गूगल ने ओरेकल के कोड का उपयोग करना चुना। न्यायाधीश विलियम अलसुप ने ओरेकल बनाम गूगल मामले में फैसला सुनाया कि एपीआई को अमेरिका में कॉपीराइट नहीं किया जा सकता है और ओरेकल की जीत से "प्रतीकों के कार्यात्मक सेट" के लिए व्यापक रूप से कॉपीराइट सुरक्षा का विस्तार होगा और सरल सॉफ़्टवेयर कमांड के कॉपीराइट की अनुमति होगी।
2010 में, ओरेकल कॉर्पोरेशन ने एंड्रॉयड ऑपरेटिंग सिस्टम में अंतर्निहित किए गए जावा के एक नए कार्यान्वयन को वितरित करने के लिए गूगल पर मुकदमा दायर किया।<ref>{{Cite web |url=http://www.drdobbs.com/jvm/232901227 |title=ओरेकल और प्रोग्रामिंग का अंत जैसा हम जानते हैं|date=2012-05-01 |publisher=DrDobbs |access-date=2012-05-09}}</ref> गूगल ने जावा एपीआई को पुन: उत्पन्न करने के लिए कोई अनुमति प्राप्त नहीं की थी, हालाँकि समान ओपेन जेडीके (OpenJDK) प्रोजेक्ट को अनुमति दी गई थी। गूगल ने अपने एपीआई के लिए एक लाइसेंस के लिए बातचीत करने के लिए ओरेकल से संपर्क किया था, लेकिन भरोसे के मुद्दों के कारण इसे ठुकरा दिया गया था। असहमति के बावजूद, गूगल ने ओरेकल के कोड का उपयोग करना चुना। न्यायाधीश विलियम अलसुप ने ओरेकल बनाम गूगल मामले में फैसला सुनाया कि एपीआई को अमेरिका में कॉपीराइट नहीं किया जा सकता है और ओरेकल की जीत से "प्रतीकों के कार्यात्मक सेट" के लिए व्यापक रूप से कॉपीराइट सुरक्षा का विस्तार होगा और सरल सॉफ़्टवेयर कमांड के कॉपीराइट की अनुमति होगी।


{{blockquote|To accept Oracle's claim would be to allow anyone to copyright one version of code to carry out a system of commands and thereby bar all others from writing its different versions to carry out all or part of the same commands.<ref>{{Cite web |url=http://www.tgdaily.com/business-and-law-features/63756-apis-cant-be-copyrighted-says-judge-in-oracle-case |title=APIs Can't be Copyrighted Says Judge in Oracle Case |date=2012-06-01 |publisher=TGDaily |access-date=2012-12-06}}</ref><ref>{{cite web
{{blockquote|ओरेकल के दावे को स्वीकार करने के लिए किसी को भी कमांड की एक प्रणाली को चलाने के लिए कोड के एक संस्करण को कॉपीराइट करने की अनुमति देना होगा और इस तरह अन्य सभी को इसके अलग-अलग संस्करणों को लिखने से रोकना होगा ताकि सभी या एक ही कमांड को पूरा किया जा सके।<ref>{{Cite web |url=http://www.tgdaily.com/business-and-law-features/63756-apis-cant-be-copyrighted-says-judge-in-oracle-case |title=APIs Can't be Copyrighted Says Judge in Oracle Case |date=2012-06-01 |publisher=TGDaily |access-date=2012-12-06}}</ref><ref>{{cite web
  | url = https://www.wired.com/wiredenterprise/wp-content/uploads/2012/05/Judge-Alsup-Ruling-on-Copyrightability-of-APIs.pdf
  | url = https://www.wired.com/wiredenterprise/wp-content/uploads/2012/05/Judge-Alsup-Ruling-on-Copyrightability-of-APIs.pdf
  | title = Oracle America, Inc. vs. Google Inc.
  | title = Oracle America, Inc. vs. Google Inc.
Line 200: Line 200:
  | publisher = [[Wired (magazine)|Wired]]
  | publisher = [[Wired (magazine)|Wired]]
}}</ref>}}
}}</ref>}}
अलसुप के फैसले को 2014 में यूनाइटेड स्टेट्स कोर्ट ऑफ अपील्स फॉर द फेडरल सर्किट में अपील पर पलट दिया गया था, हालांकि एपीआई के इस तरह के उपयोग से उचित उपयोग का सवाल अनसुलझा रह गया था।<ref>{{Cite web|title=Oracle Am., Inc. बनाम Google Inc., संख्या 13-1021, Fed. सर्क। 2014|url=https://law.justia.com/cases/federal/appellate-courts/cafc/13-1021/13-1021-2014-05-09.html|url-status=live|archive-url=https://web.archive.org/web/20141010070718/http://law.justia.com:80/cases/federal/appellate-courts/cafc/13-1021/13-1021-2014-05-09.html |archive-date=2014-10-10 }}</ref><ref>{{Cite news |last=Rosenblatt, Seth |url=https://www.cnet.com/news/court-sides-with-oracle-over-android-in-java-patent-appeal/ |title=जावा पेटेंट अपील में Android पर Oracle के साथ कोर्ट का पक्ष|date=May 9, 2014 |work=CNET |access-date=2014-05-10}}</ref>
 
2016 में, दो सप्ताह के परीक्षण के बाद, एक जूरी ने निर्धारित किया कि जावा एपीआई के Google के पुन: कार्यान्वयन ने उचित उपयोग का गठन किया, लेकिन ओरेकल ने निर्णय की अपील करने की कसम खाई।<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 Oracle को हराता है - Android Java API का "उचित उपयोग" करता है|date=2016-05-26 |website=Ars Technica |access-date=2016-07-28}}</ref> ओरेकल ने अपनी अपील पर जीत हासिल की, कोर्ट ऑफ अपील्स फॉर द फेडरल सर्किट के फैसले के साथ कि Google द्वारा एपीआई का उपयोग उचित उपयोग के लिए योग्य नहीं था।<ref name="bbn march2018">{{Cite web |url=https://www.bloomberg.com/news/articles/2018-03-27/oracle-wins-revival-of-billion-dollar-case-against-google |title=ऑरेकल ने गूगल के खिलाफ बिलियन-डॉलर केस का पुनरुद्धार जीता|last=Decker |first=Susan |date=March 27, 2018 |website=[[Bloomberg Businessweek]] |access-date=March 27, 2018}}</ref> 2019 में, Google ने संयुक्त राज्य के सर्वोच्च न्यायालय में कॉपीराइट योग्यता और उचित उपयोग दोनों के निर्णयों पर अपील की, और सर्वोच्च न्यायालय ने समीक्षा की अनुमति दी।<ref name="ars Jan2019">{{Cite web |url=https://arstechnica.com/tech-policy/2019/01/google-asks-supreme-court-to-overrule-disastrous-ruling-on-api-copyrights/ |title=Google ने सर्वोच्च न्यायालय से एपीआई कॉपीराइट पर विनाशकारी फैसले को रद्द करने के लिए कहा|last=Lee |first=Timothy |date=January 25, 2019 |website=[[Ars Technica]] |access-date=February 8, 2019}}</ref> COVID-19 महामारी के कारण, मामले की मौखिक सुनवाई अक्टूबर 2020 तक विलंबित हो गई।<ref>{{Cite web|last=vkimber|date=2020-09-28|title=Google LLC v. Oracle अमेरिका, Inc.|url=https://www.law.cornell.edu/supct/cert/18-956|access-date=2021-03-06|website=LII / Legal Information Institute|language=en}}</ref>
अलसुप के फैसले को 2014 में संघीय सर्किट के लिए अपील की अदालत में अपील पर पलट दिया गया था, हालांकि इस तरह के एपीआई के उपयोग से उचित उपयोग का सवाल अनसुलझा रह गया था।<ref>{{Cite web|title=Oracle Am., Inc. बनाम Google Inc., संख्या 13-1021, Fed. सर्क। 2014|url=https://law.justia.com/cases/federal/appellate-courts/cafc/13-1021/13-1021-2014-05-09.html|url-status=live|archive-url=https://web.archive.org/web/20141010070718/http://law.justia.com:80/cases/federal/appellate-courts/cafc/13-1021/13-1021-2014-05-09.html |archive-date=2014-10-10 }}</ref><ref>{{Cite news |last=Rosenblatt, Seth |url=https://www.cnet.com/news/court-sides-with-oracle-over-android-in-java-patent-appeal/ |title=जावा पेटेंट अपील में Android पर Oracle के साथ कोर्ट का पक्ष|date=May 9, 2014 |work=CNET |access-date=2014-05-10}}</ref>
इस मामले का फैसला सुप्रीम कोर्ट ने 6-2 के फैसले के साथ Google के पक्ष में दिया था। न्यायमूर्ति स्टीफन ब्रेयर ने अदालत की राय दी और एक बिंदु पर उल्लेख किया कि घोषित कोड कॉपीराइट के मूल से अधिकांश कंप्यूटर प्रोग्रामों की तुलना में कॉपीराइट योग्य है। इसका अर्थ है कि कॉपीराइट सुरक्षा के मामले में एपीआई में उपयोग किए गए कोड उपन्यासों की तुलना में शब्दकोशों के समान हैं।<ref>{{Cite web|date=April 5, 2021|title=संयुक्त राज्य अमेरिका का सर्वोच्च न्यायालय, नंबर 18–956, GOOGLE LLC, याचिकाकर्ता बनाम Oracle अमेरिका, INC।|url=https://www.supremecourt.gov/opinions/20pdf/18-956_d18f.pdf}}</ref>
 
2016 में, दो सप्ताह के परीक्षण के बाद, एक जूरी ने निर्धारित किया कि जावा एपीआई के गूगल के पुन: कार्यान्वयन ने उचित उपयोग का गठन किया, लेकिन ओरेकल ने निर्णय की अपील करने की कसम खाई।<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 Oracle को हराता है - Android Java API का "उचित उपयोग" करता है|date=2016-05-26 |website=Ars Technica |access-date=2016-07-28}}</ref> ओरेकल ने अपनी अपील पर संघीय सर्किट के लिए अपील की अदालत के फैसले के साथ जीत हासिल की कि गूगल द्वारा एपीआई का उपयोग उचित उपयोग के लिए योग्य नहीं था।<ref name="bbn march2018">{{Cite web |url=https://www.bloomberg.com/news/articles/2018-03-27/oracle-wins-revival-of-billion-dollar-case-against-google |title=ऑरेकल ने गूगल के खिलाफ बिलियन-डॉलर केस का पुनरुद्धार जीता|last=Decker |first=Susan |date=March 27, 2018 |website=[[Bloomberg Businessweek]] |access-date=March 27, 2018}}</ref> 2019 में, गूगल ने संयुक्त राज्य अमेरिका के सर्वोच्च न्यायालय में कॉपीराइट योग्यता और उचित उपयोग दोनों के निर्णयों पर अपील की, और सर्वोच्च न्यायालय ने समीक्षा की अनुमति दी।<ref name="ars Jan2019">{{Cite web |url=https://arstechnica.com/tech-policy/2019/01/google-asks-supreme-court-to-overrule-disastrous-ruling-on-api-copyrights/ |title=Google ने सर्वोच्च न्यायालय से एपीआई कॉपीराइट पर विनाशकारी फैसले को रद्द करने के लिए कहा|last=Lee |first=Timothy |date=January 25, 2019 |website=[[Ars Technica]] |access-date=February 8, 2019}}</ref> कोविड-19 महामारी के कारण, मामले की मौखिक सुनवाई अक्टूबर 2020 तक विलंबित हो गई थी।<ref>{{Cite web|last=vkimber|date=2020-09-28|title=Google LLC v. Oracle अमेरिका, Inc.|url=https://www.law.cornell.edu/supct/cert/18-956|access-date=2021-03-06|website=LII / Legal Information Institute|language=en}}</ref>
 
इस मामले का फैसला सुप्रीम कोर्ट ने 6-2 के फैसले के साथ गूगल के पक्ष में दिया था। न्यायमूर्ति स्टीफन ब्रेयर ने अदालत की राय दी और एक बिंदु पर उल्लेख किया कि "घोषित कोड कॉपीराइट के मूल से अधिकांश कंप्यूटर प्रोग्रामों की तुलना में आगे कॉपीराइट योग्य है।" इसका मतलब यह है कि कॉपीराइट सुरक्षा के मामले में एपीआई में उपयोग किए गए कोड उपन्यासों की तुलना में शब्दकोशों के समान हैं।<ref>{{Cite web|date=April 5, 2021|title=संयुक्त राज्य अमेरिका का सर्वोच्च न्यायालय, नंबर 18–956, GOOGLE LLC, याचिकाकर्ता बनाम Oracle अमेरिका, INC।|url=https://www.supremecourt.gov/opinions/20pdf/18-956_d18f.pdf}}</ref>
== उदाहरण ==
== उदाहरण ==
{{Main category|Application programming interfaces}}
{{Main category|एप्लिकेशन प्रोग्रामिंग इंटरफेस}}


{{Div col}}
{{Div col}}
* SCSI डिवाइस इंटरफेसिंग के लिए उन्नत SCSI प्रोग्रामिंग इंटरफ़ेस
* एससीएसआई (SCSI) डिवाइस इंटरफेसिंग के लिए एएसपीआई (ASPI)।
* मैकिंटोश के लिए कोको (एपीआई) और कार्बन (एपीआई)।
* मैकिंटोश के लिए कोको और कार्बन।
* माइक्रोसॉफ्ट विंडोज के लिए डायरेक्टएक्स
* माइक्रोसॉफ्ट विंडोज के लिए डायरेक्टएक्स।
* एहल्लापि
* ईएचएलएलएपीआई (EHLLAPI)।
* जावा एपीआई की सूची
* जावा एपीआई।
* माइक्रोसॉफ्ट विंडोज के लिए ओपन डाटाबेस कनेक्टिविटी
* माइक्रोसॉफ्ट विंडोज के लिए ओडीबीसी (ODBC)।
* ओपनएएल क्रॉस-प्लेटफॉर्म साउंड एपीआई
* ओपनएएल (OpenAL) क्रॉस-प्लेटफ़ॉर्म ध्वनि एपीआई।
* सीपीयू और जीपीयू के लिए सामान्य प्रयोजन कंप्यूटिंग के लिए ओपनसीएल क्रॉस-प्लेटफॉर्म एपीआई
* सीपीयू (CPU) और जीपीयू (GPU) के लिए सामान्य प्रयोजन कंप्यूटिंग के लिए ओपनसीएल (OpenCL) क्रॉस-प्लेटफॉर्म एपीआई।
* ओपनजीएल क्रॉस-प्लेटफॉर्म ग्राफिक्स एपीआई
* ओपनजीएल (OpenGL) क्रॉस-प्लेटफार्म ग्राफिक्स एपीआई।
* ओपनएमपी एपीआई जो यूनिक्स और माइक्रोसॉफ्ट विंडोज प्लेटफॉर्म सहित कई आर्किटेक्चर पर सी, सी ++ और फोरट्रान में मल्टी-प्लेटफॉर्म शेयर्ड मेमोरी मल्टीप्रोसेसिंग प्रोग्रामिंग का समर्थन करता है।
* ओपनएमपी एपीआई जो यूनिक्स और माइक्रोसॉफ्ट विंडोज प्लेटफॉर्म समेत कई आर्किटेक्चर पर सी (C), सी ++ (C++) और फोरट्रान में मल्टी-प्लेटफार्म साझा मेमोरी मल्टीप्रोसेसिंग प्रोग्रामिंग का समर्थन करता है।
* सर्वर अनुप्रयोग प्रोग्रामिंग इंटरफ़ेस (SAPI)
* सर्वर एप्लिकेशन प्रोग्रामिंग इंटरफ़ेस (एसएपीआई)
* सिंपल डायरेक्टमीडिया लेयर (SDL)
* सरल डायरेक्टमीडिया परत (एसडीएल){{Div col end}}
{{Div col end}}


== यह भी देखें ==
== यह भी देखें ==
Line 228: Line 230:
* कॉलिंग कन्वेंशन
* कॉलिंग कन्वेंशन
*कॉमन ऑब्जेक्ट रिक्वेस्ट ब्रोकर आर्किटेक्चर (कॉरबा)
*कॉमन ऑब्जेक्ट रिक्वेस्ट ब्रोकर आर्किटेक्चर (कॉरबा)
*आवेदन आभासी मशीनों की तुलना
*एप्लिकेशन वर्चुअल मशीनों की तुलना
*डॉक्यूमेंट ऑब्जेक्ट मॉडल (DOM)
*लेख ऑब्जेक्ट मॉडल (DOM)
*डबल-चांस फंक्शन
*डबल-चांस फंक्शन
* विदेशी फ़ंक्शन इंटरफ़ेस
* विदेशी फ़ंक्शन इंटरफ़ेस
*आगे और पीछे के सिरे
*आगे और पीछे के सिरे
* इंटरफ़ेस (कंप्यूटिंग)
* इंटरफ़ेस (कंप्यूटिंग)
* इंटरफ़ेस नियंत्रण दस्तावेज़
* इंटरफ़ेस नियंत्रण लेख
*3डी ग्राफिक्स एपीआई की सूची
*3डी ग्राफिक्स एपीआई की सूची
* माइक्रोसर्विसेज
* माइक्रोसर्विसेज
* नाम मैंगलिंग
* नाम मैंगलिंग
* ओपन एपीआई
* ओपन एपीआई
* ओपन सर्विस इंटरफेस डेफिनिशन
* ओपन सर्विस इंटरफेस परिभाषाएँ
* पार्सिंग
* पार्सिंग
* प्लग-इन (कंप्यूटिंग)
* प्लग-इन
* आरएएमएल (सॉफ्टवेयर)
* आरएएमएल (सॉफ्टवेयर)
*सॉफ्टवेयर डेवलपमेंट किट (एसडीके)
*सॉफ्टवेयर डेवलपमेंट किट (एसडीके)
* वेब एपीआई
* संरचित वित्तीय संदेश प्रणाली
*वेब एपीआई
*वेब सामग्री विक्रेता
*वेब सामग्री विक्रेता
*एक्सपीकॉम
*एक्सपीकॉम
Line 257: Line 260:
* [https://www.supremecourt.gov/opinions/20pdf/18-956_d18f.pdf  What is an API?] – in the U.S. Supreme [[Court opinion]], [[Google LLC v. Oracle America, Inc.|Google v. Oracle 2021]], pp.&nbsp;3–7 – "For each task, there is [[computer code]]; API (also known as [[Application Program Interface]]) is the method for calling that '[[computer code]]' (instruction – like a [[recipe]] – rather than cooking instruction, this is [[Computer|machine]] instruction) to be carry out"
* [https://www.supremecourt.gov/opinions/20pdf/18-956_d18f.pdf  What is an API?] – in the U.S. Supreme [[Court opinion]], [[Google LLC v. Oracle America, Inc.|Google v. Oracle 2021]], pp.&nbsp;3–7 – "For each task, there is [[computer code]]; API (also known as [[Application Program Interface]]) is the method for calling that '[[computer code]]' (instruction – like a [[recipe]] – rather than cooking instruction, this is [[Computer|machine]] instruction) to be carry out"
* [http://ondrejka.net/history/2014/02/28/maury.html Maury, Innovation and Change] – Cory Ondrejka \ February 28, 2014 \ " ...proposed a public API to let computers talk to each other". ([https://www.textise.net/showText.aspx?strURL=http://ondrejka.net/history/2014/02/28/maury.html Textise] URL)
* [http://ondrejka.net/history/2014/02/28/maury.html Maury, Innovation and Change] – Cory Ondrejka \ February 28, 2014 \ " ...proposed a public API to let computers talk to each other". ([https://www.textise.net/showText.aspx?strURL=http://ondrejka.net/history/2014/02/28/maury.html Textise] URL)
==इस पेज में लापता आंतरिक लिंक की सूची==
==बाहरी संबंध==
==बाहरी संबंध==
* [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
* [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

Revision as of 18:17, 1 January 2023

नासा द्वारा लिखित वेब एपीआई प्रलेखन का स्क्रीनशॉट।

एक एप्लिकेशन प्रोग्रामिंग इंटरफ़ेस (एपीआई) दो या दो से अधिक कंप्यूटर प्रोग्रामों के लिए एक दूसरे के साथ संवाद करने का एक तरीका है। यह एक प्रकार का सॉफ़्टवेयर इंटरफ़ेस है, जो सॉफ़्टवेयर के अन्य भागों को सेवा प्रदान करता है।[1] एक दस्तावेज़ या मानक जो वर्णन करता है कि इस तरह के संबंध या इंटरफ़ेस को कैसे बनाया या उपयोग किया जाए, उसे एपीआई विनिर्देश कहा जाता है। एक कंप्यूटर प्रणाली जो इस मानक को पूरा करता है, उसे एपीआई को लागू करने या प्रदर्शित करने के लिए कहा जाता है। एपीआई शब्द विनिर्देश या कार्यान्वयन के लिए संदर्भित हो सकता है।

एक यूजर इंटरफेस के विपरीत, जो एक कंप्यूटर को एक व्यक्ति से जोड़ता है, एक एप्लिकेशन प्रोग्रामिंग इंटरफेस कंप्यूटर या सॉफ्टवेयर के भागों को एक दूसरे से जोड़ता है। यह एक कंप्यूटर प्रोग्रामर के अलावा किसी अन्य व्यक्ति (अंतिम उपयोगकर्ता) द्वारा सीधे उपयोग किए जाने के लिए अभिप्रेत नहीं है जो इसे सॉफ्टवेयर में सम्मिलित कर रहा है। एक एपीआई प्रायः विभिन्न भागों से बना होता है जो प्रोग्रामर के लिए उपलब्ध उपकरण या सेवाओं के रूप में कार्य करता है। एक प्रोग्राम या प्रोग्रामर जो इन भागों में से एक का उपयोग करता है, उसे एपीआई के उस हिस्से को कॉल करने के लिए कहा जाता है। एपीआई बनाने वाली कॉल को सबरूटीन्स, विधियों, अनुरोधों या समापन बिंदुओं के रूप में भी जाना जाता है। एक एपीआई विनिर्देश इन कॉलों को परिभाषित करता है, जिसका अर्थ है कि यह बताता है कि उनका उपयोग कैसे करें या उन्हें कैसे कार्यान्वित करें।

एपीआई का एक उद्देश्य आंतरिक विवरणों को छिपाना है कि एक प्रणाली कैसे काम करती है, केवल उन हिस्सों को प्रकट करता है जो प्रोग्रामर को उपयोगी लगेगा और आंतरिक विवरण बाद में बदल जाने पर भी उन्हें सुसंगत बनाए रखेगा। एक एपीआई प्रणाली की एक विशेष जोड़ी के लिए कस्टम-निर्मित हो सकता है, या यह एक साझा मानक हो सकता है जो कई प्रणालियों के बीच इंटरऑपरेबिलिटी की अनुमति देता है।

एपीआई शब्द का प्रयोग प्रायः वेब एपीआई को संदर्भित करने के लिए किया जाता है,[2] जो इंटरनेट से जुड़े कंप्यूटरों के बीच संचार की अनुमति देता है। प्रोग्रामिंग भाषाओं, सॉफ्टवेयर लाइब्रेरी, कंप्यूटर ऑपरेटिंग सिस्टम और कंप्यूटर हार्डवेयर के लिए एपीआई भी हैं। एपीआई की उत्पत्ति 1940 के दशक में हुई थी, हालांकि यह शब्द 1960 और 1970 के दशक तक सामने नहीं आया था। एपीआई में हाल के विकास ने माइक्रोसर्विसेज की लोकप्रियता में वृद्धि की है, जो सार्वजनिक एपीआई के माध्यम से अभिगम की जाने वाली शिथिल युग्मित सेवाएं हैं।[3]

उद्देश्य

अनुप्रयोगों के निर्माण में, एक एपीआई अंतर्निहित कार्यान्वयन को सारणित करके प्रोग्रामिंग को सरल बनाता है और केवल उन वस्तुओं या कार्यों को प्रकट करता है जिनकी डेवलपर को आवश्यकता होती है। जबकि एक ईमेल क्लाइंट के लिए ग्राफिकल इंटरफ़ेस उपयोगकर्ता को एक बटन प्रदान कर सकता है जो नए ईमेल लाने और स्पष्ट करने के लिए सभी चरणों का पालन करता है, फ़ाइल इनपुट/आउटपुट के लिए एक एपीआई डेवलपर को एक ऐसा फ़ंक्शन दे सकता है जो फ़ाइल को एक स्थान से दूसरे स्थान पर कॉपी करता है इस आवश्यकता के बिना कि डेवलपर दृश्यों के पीछे होने वाली फाइल प्रणाली संचालन को समझता है।[4]

शब्द का इतिहास

File:Database management system diagram from 1978 workshop.png
1978 का एक रेखाचित्र, केवल एप्लिकेशन प्रोग्राम से परे, एक सामान्य प्रोग्रामिंग इंटरफ़ेस बनने के लिए एपीआई के विचार के विस्तार का प्रस्ताव करता है।[5]

एपीआई शब्द प्रारम्भ में केवल एंड-यूज़र-फेसिंग प्रोग्राम के लिए एक इंटरफ़ेस का वर्णन करता है, जिसे एप्लिकेशन प्रोग्राम के रूप में जाना जाता है। यह उत्पत्ति अभी भी "एप्लिकेशन प्रोग्रामिंग इंटरफ़ेस" के नाम से परिलक्षित होती है। आज, यह शब्द व्यापक है, जिसमें उपयोगिता (यूटिलिटी) सॉफ्टवेयर और यहां तक कि हार्डवेयर इंटरफेस भी सम्मिलित हैं।[6]

1940 और 1950 के दशक

API का विचार स्वयं शब्द से बहुत पुराना है। ब्रिटिश कंप्यूटर वैज्ञानिक मौरिस विल्क्स और डेविड व्हीलर ने 1940 के दशक में एक प्रारंभिक कंप्यूटर ईडीएसएसी (EDSAC) के लिए एक मॉड्यूलर सॉफ्टवेयर लाइब्रेरी पर काम किया। इस लाइब्रेरी में सबरूटीन्स को फाइलिंग कैबिनेट में व्यवस्थित पंच पेपर टेप पर संग्रहित किया गया था। इस कैबिनेट में यह भी सम्मिलित है कि विल्क्स और व्हीलर ने प्रत्येक सबरूटीन के बारे में नोट्स की एक "लाइब्रेरी कैटलॉग" को क्या कहा और इसे एक प्रोग्राम में कैसे सम्मिलित किया जाए। आज, इस तरह के कैटलॉग को एपीआई (या एपीआई विनिर्देश या एपीआई दस्तावेज) कहा जाएगा क्योंकि यह एक प्रोग्रामर को निर्देश देता है कि प्रोग्रामर को प्रत्येक सबरूटीन का उपयोग (या "कॉल") कैसे करें।[6]

विल्क्स एंड व्हीलर की 1951 की किताब एक इलेक्ट्रॉनिक डिजिटल कंप्यूटर के लिए प्रोग्राम तैयार करने में पहला प्रकाशित एपीआई विनिर्देश सम्मिलित है। जोशुआ बलोच का मानना है कि विल्क्स और व्हीलर ने "अव्यक्त रूप से एपीआई का आविष्कार" किया क्योंकि यह एक ऐसी अवधारणा है जिसे खोजा गया है न कि आविष्कार किया गया है।[6]

Although the people who coined the term API were implementing software on a UNIVAC 1100/2200 श्रृंखला #1108, उनके एपीआई का लक्ष्य हार्डवेयर स्वतंत्र कार्यक्रमों को संभव बनाना था।[7]

1960 और 1970 के दशक

शब्द "एप्लिकेशन प्रोग्राम इंटरफ़ेस" (बिना -आईएनजी प्रत्यय के) पहली बार 1968 में एएफआईपीएस (AFIPS) सम्मेलन में प्रस्तुत रिमोट कंप्यूटर ग्राफिक्स के लिए डेटा संरचना और तकनीक नामक एक पेपर में दर्ज किया गया था।[8][6] इस पेपर के लेखक इस स्थिति में बाकी कंप्यूटर प्रणाली के साथ एक ग्राफिक प्रोग्राम की परस्पर क्रिया का वर्णन करने के लिए इस शब्द का उपयोग करते हैं। एक सुसंगत एप्लिकेशन इंटरफ़ेस (फोरट्रान सबरूटीन कॉल्स से मिलकर) का उद्देश्य प्रोग्रामर को ग्राफिक्स डिस्प्ले डिवाइस विशिष्टताओं से निपटने से मुक्त करना और कंप्यूटर या डिस्प्ले को बदलने पर हार्डवेयर स्वतंत्रता प्रदान करना था।[7]

डेटाबेस के क्षेत्र में इस शब्द का परिचय सी.जे. डेट[9] ने 1974 में द रिलेशनल एंड नेटवर्क एप्रोचेज़: कम्पेरिज़न ऑफ़ द एप्लिकेशन प्रोग्रामिंग इंटरफ़ेस नामक एक पेपर में किया था।[10] एक एपीआई डेटाबेस प्रबंधन प्रणालियों के लिए एएनएसआई/स्पार्क रूपरेखा का हिस्सा बन गया। इस रूपरेखा ने एप्लिकेशन प्रोग्रामिंग इंटरफ़ेस को अन्य इंटरफेस, जैसे कि जांच इंटरफ़ेस से अलग से व्यवहार किया। 1970 के दशक में डाटाबेस पेशेवरों ने देखा कि इन विभिन्न इंटरफेसों को जोड़ा जा सकता है पर्याप्त रूप से समृद्ध एप्लिकेशन इंटरफ़ेस अन्य इंटरफेसों का भी समर्थन कर सकता है।[5]

इस अवलोकन ने एपीआई का नेतृत्व किया जो सभी प्रकार की प्रोग्रामिंग का समर्थन करता था, न कि केवल एप्लिकेशन प्रोग्रामिंग का।

1990 के दशक

1990 तक, प्रौद्योगिकीविद् कार्ल मलामुद द्वारा एपीआई को "कुछ कार्यों को करने के लिए एक प्रोग्रामर के लिए उपलब्ध सेवाओं का एक सेट" के रूप में परिभाषित किया गया था।[11]

दूरस्थ प्रक्रिया कॉल और वेब एपीआई का प्रारम्भ के साथ एपीआई के विचार को फिर से विस्तारित किया गया। चूंकि 1970 और 1980 के दशक में कंप्यूटर नेटवर्क सामान्य हो गए थे, प्रोग्रामर न केवल अपने स्थानीय कंप्यूटरों पर बल्कि अन्यत्र स्थित कंप्यूटरों पर स्थित लाइब्रेरी को कॉल चाहते थे ये दूरस्थ प्रक्रिया कॉल विशेष रूप से जावा भाषा द्वारा अच्छी तरह से समर्थित थे। 1990 के दशक में, इंटरनेट के प्रसार के साथ, कोरबा (CORBA), कॉम (COM), और डीकॉम (DCOM) जैसे मानकों ने एपीआई सेवाओं को प्रकट करने का सबसे सामान्य तरीका बनने के लिए प्रतिस्पर्धा की।[12]

2000 के दशक

2000 में यूसी इरविन में रॉय फील्डिंग के शोध प्रबंध आर्किटेक्चरल स्टाइल्स और नेटवर्क-आधारित सॉफ़्टवेयर आर्किटेक्चर के डिज़ाइन ने प्रतिनिधित्ववादी स्थिति में स्थानांतरण (आरईएसटी) को रेखांकित किया और "नेटवर्क-आधारित एप्लिकेशन प्रोग्रामिंग इंटरफेस" के विचार का वर्णन किया, जो फील्डिंग पारंपरिक "लाइब्रेरी-आधारित" एपीआई के विपरीत है।[13] एक्सएमएल (XML) और जेएसओएन (JSON) वेब एपीआई ने 2000 में व्यापक व्यावसायिक स्वीकृति देखी और 2022 तक जारी रही। वेब एपीआई अब एपीआई शब्द का सबसे सामान्य अर्थ है।[2]

2001 में टिम बर्नर्स-ली द्वारा प्रस्तावित सिमेंटिक वेब में "सिमेंटिक एपीआई" सम्मिलित था जो एपीआई को एक सॉफ्टवेयर व्यवहार इंटरफेस के स्थान पर एक खुले वितरित डेटा इंटरफेस के रूप में पुन: प्रस्तुत करता है।[14] स्वामित्व इंटरफेस और एजेंट खुले इंटरफेस की तुलना में अधिक व्यापक हो गए लेकिन डेटा इंटरफेस के रूप में एपीआई के विचार ने जोर पकड़ लिया। क्योंकि वेब एपीआई का व्यापक रूप से सभी प्रकार के ऑनलाइन डेटा के आदान-प्रदान के लिए उपयोग किया जाता है, एपीआई एक व्यापक शब्द बन गया है जो इंटरनेट पर अधिकांश संचार का वर्णन करता है।[12] जब इस तरह से उपयोग किया जाता है, तो एपीआई शब्द का अर्थ संचार प्रोटोकॉल शब्द के साथ अधिव्याप्त होता है।== उपयोग ==

लाइब्रेरी और रूपरेखा

सॉफ्टवेयर लाइब्रेरी का इंटरफ़ेस एक प्रकार का एपीआई है। एपीआई "अपेक्षित व्यवहार" (एक विनिर्देश) का वर्णन करता और निर्धारित करता है, जबकि लाइब्रेरी नियमों के इस सेट का "वास्तविक कार्यान्वयन" है।

एक ही प्रोग्रामिंग इंटरफेस को साझा करने वाली विभिन्न लाइब्रेरी के रूप में एक एकल एपीआई में कई कार्यान्वयन (या कोई नहीं, निराकार होने) हो सकते हैं।

एपीआई को इसके कार्यान्वयन से अलग करने से एक भाषा में लिखे गए प्रोग्राम को दूसरी भाषा में लिखी गई लाइब्रेरी का उपयोग करने की अनुमति मिल सकती है। उदाहरण के लिए, क्योंकि स्काला और जावा संगत बाइटकोड को संकलित करते हैं, स्काला डेवलपर्स किसी भी जावा एपीआई का लाभ उठा सकते हैं।[15]

एपीआई का उपयोग सम्मिलित प्रोग्रामिंग भाषा के प्रकार के आधार पर भिन्न हो सकता है। लुआ जैसी प्रक्रियात्मक भाषा के लिए एक एपीआई में मुख्य रूप से कोड को निष्पादित करने, डेटा में हेरफेर करने या त्रुटियों को संभालने के लिए बुनियादी दिनचर्या सम्मिलित हो सकती हैं, जबकि ऑब्जेक्ट-ओरिएंटेड भाषा के लिए एक एपीआई, जैसे कि जावा, कक्षाओं और इसकी कक्षा विधियों का एक विनिर्देश प्रदान करेगा।[16][17] हिरुम का नियम[18] कहता है कि "एपीआई के उपयोगकर्ताओं की पर्याप्त संख्या के साथ इससे कोई फर्क नहीं पड़ता कि आप अनुबंध में क्या वादा करते हैं- आपकी प्रणाली के सभी अवलोकन योग्य व्यवहार किसी के द्वारा निर्भर होंगे।" इस बीच, कई अध्ययनों से पता चलता है कि एपीआई का उपयोग करने वाले अधिकांश एप्लिकेशन एपीआई के एक छोटे से हिस्से का उपयोग करते हैं।[19] एपीआई का उपयोग वास्तव में उपयोगकर्ताओं की संख्या के साथ-साथ एपीआई की लोकप्रियता पर निर्भर करता है।[20]

भाषा बंधन (लैंग्वेज बाइंडिंग) भी एपीआई हैं। भाषा की विशेषताओं और क्षमताओं को दूसरी भाषा में कार्यान्वित इंटरफ़ेस से मैप करके, भाषा बंधन एक भाषा में लिखी गई लाइब्रेरी या सेवा को दूसरी भाषा में विकसित करते समय उपयोग करने की अनुमति देता है।[21]

एसडब्ल्यूआईजी (SWIG) और एफ2पीवाई (F2PY) और जैसे फोरट्रान-से-पायथन इंटरफेस जनित्र ऐसे इंटरफेस के निर्माण की सुविधा प्रदान करते हैं।[22]

एक एपीआई एक सॉफ्टवेयर रूपरेखा से भी संबंधित हो सकता है- एक रूपरेखा कई लाइब्रेरी पर आधारित हो सकता है जो कई एपीआई को लागू करता है, लेकिन एक एपीआई के सामान्य उपयोग के विपरीत, रूपरेखा में निर्मित व्यवहार तक पहुंच की मध्यस्थता इसकी सामग्री को रूपरेखा में लगाए गए नए वर्गों के साथ विस्तारित करके की जाती है।

इसके अलावा, नियंत्रण का समग्र प्रोग्राम प्रवाह कॉल करने वाले के नियंत्रण से बाहर और नियंत्रण के व्युत्क्रम या इसी तरह के तंत्र द्वारा रूपरेखा के हाथों में हो सकता है।[23][24]

ऑपरेटिंग सिस्टम

एक एपीआई एप्लिकेशन और ऑपरेटिंग सिस्टम के बीच इंटरफेस को निर्दिष्ट कर सकता है।[25] पीओएसआईएक्स (POSIX), उदाहरण के लिए, सामान्य एपीआई विनिर्देशों का एक सेट प्रदान करता है जिसका उद्देश्य पीओएसआईएक्स (POSIX) अनुरूप ऑपरेटिंग सिस्टम के लिए लिखे गए एप्लिकेशन को अन्य पीओएसआईएक्स (POSIX) अनुरूप ऑपरेटिंग सिस्टम के लिए संकलित करने में सक्षम बनाना है।

लिनक्स और बर्कले सॉफ्टवेयर वितरण ऑपरेटिंग सिस्टम के उदाहरण हैं जो पीओएसआईएक्स (POSIX) एपीआई को लागू करते हैं।[26]

माइक्रोसॉफ्ट ने विशेष रूप से अपने विंडोज एपीआई (Win32) लाइब्रेरी के भीतर एक पिछड़े-संगत एपीआई के लिए एक मजबूत प्रतिबद्धता दिखाई है, इसलिए पुराने एप्लिकेशन "संगतता मोड" नामक निष्पादन योग्य-विशिष्ट सेटिंग का उपयोग करके विंडोज के नए संस्करणों पर चल सकते हैं।[27]

एक एपीआई एक एप्लिकेशन बाइनरी इंटरफ़ेस (एबीआई) से अलग है जिसमें एपीआई स्रोत कोड आधारित है जबकि एबीआई बाइनरी आधारित है। उदाहरण के लिए, पीओएसआईएक्स (POSIX) एपीआई प्रदान करता है जबकि लिनक्स मानक आधार एबीआई प्रदान करता है।[28][29]

रिमोट एपीआई

रिमोट एपीआई डेवलपर्स को प्रोटोकॉल के माध्यम से रिमोट संसाधनों में हेरफेर करने की अनुमति देते हैं, संचार के लिए विशिष्ट मानक जो भाषा या प्लेटफॉर्म की परवाह किए बिना विभिन्न तकनीकों को एक साथ काम करने की अनुमति देते हैं। उदाहरण के लिए, जावा डाटाबेस सम्बन्ध एपीआई डेवलपर्स को कार्यों के एक ही सेट के साथ कई अलग-अलग प्रकार के डेटाबेस को जांच करने की अनुमति देता है, जबकि जावा रिमोट विधि आह्वान एपीआई जावा रिमोट विधि प्रोटोकॉल का उपयोग करता है जो रिमोट रूप से संचालित होने वाले कार्यों के आह्वान की अनुमति देता है। लेकिन डेवलपर को स्थानीय दिखाई देते हैं।[30][31]

इसलिए, रिमोट एपीआई ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग में ऑब्जेक्ट को निराकार बनाए रखने में उपयोगी होते हैं प्रतिनिधि संबंधी ऑब्जेक्ट पर स्थानीय रूप से निष्पादित एक विधि कॉल, रिमोटिंग प्रोटोकॉल का उपयोग करके रिमोट ऑब्जेक्ट पर संबंधित विधि को आमंत्रित करता है, और परिणाम को स्थानीय रूप से वापसी मान के रूप में उपयोग करने के लिए प्राप्त करता है।

प्रतिनिधि संबंधी ऑब्जेक्ट के एक संशोधन के परिणामस्वरूप रिमोट ऑब्जेक्ट का एक संगत संशोधन भी होगा।[32]

वेब एपीआई

वेब एपीआई हाइपरटेक्स्ट ट्रांसफर प्रोटोकॉल (एचटीटीपी) का उपयोग कर क्लाइंट डिवाइस (मोबाइल फोन, लैपटॉप इत्यादि) से वेब सर्वर तक पहुंचने वाली सेवा है। क्लाइंट डिवाइस एचटीटीपी (HTTP) अनुरोध के रूप में भेजते हैं, और प्रायः जावास्क्रिप्ट ऑब्जेक्ट नोटेशन (JSON) या एक्स्टेंसिबल मार्कअप लैंग्वेज (XML) प्रारूप में प्रतिक्रिया संदेश के साथ मिलती हैं। डेवलपर्स प्रायः वेब एपीआई का उपयोग उस सर्वर से डेटा के एक विशिष्ट सेट के लिए सर्वर जांच करने के लिए करते हैं।

उदाहरण एक शिपिंग कंपनी एपीआई हो सकती है जिसे शिपिंग सेवाओं को ऑर्डर करने की सुविधा के लिए ईकामर्स-केंद्रित वेबसाइट में जोड़ा जा सकता है और साइट डेवलपर को वेब डेटाबेस में शिपर की दर तालिका में प्रवेश किए बिना स्वचालित रूप से वर्तमान शिपिंग दरों को सम्मिलित किया जा सकता है। जबकि "वेब एपीआई" ऐतिहासिक रूप से वेब सेवा का वस्तुतः पर्याय रहा है, हाल की प्रवृत्ति (तथाकथित वेब 2.0) सिंपल ऑब्जेक्ट एक्सेस प्रोटोकॉल (SOAP) आधारित वेब सेवाओं और सेवा-उन्मुख आर्किटेक्चर (SOA) से अधिक प्रत्यक्ष प्रतिनिधित्वात्मक स्थिति स्थानांतरण (REST), शैली वेब संसाधन और संसाधन-उन्मुख आर्किटेक्चर (ROA) की ओर बढ़ रही है।[33] इस प्रवृत्ति का एक हिस्सा सिमेंटिक वेब गतिविधि से संसाधन विवरण रूपरेखा (RDF) से संबंधित है, जो वेब-आधारित ऑन्टोलॉजी इंजीनियरिंग तकनीकों को बढ़ावा देने के लिए एक अवधारणा है। वेब एपीआई मैशअप के रूप में ज्ञात नए अनुप्रयोगों में कई एपीआई के संयोजन की अनुमति देता है।[34]

सोशल मीडिया स्पेस में, वेब एपीआई ने वेब समुदायों को समुदायों और एप्लिकेशन के बीच सामग्री और डेटा साझा करने की सुविधा प्रदान करने की अनुमति दी है। इस प्रकार, एक स्थान पर गतिशील रूप से बनाई गई सामग्री को वेब पर कई स्थानों पर पोस्ट और अपडेट किया जा सकता है।[35] उदाहरण के लिए, ट्विटर का रेस्ट एपीआई डेवलपर्स को कोर ट्विटर डेटा तक पहुंचने की अनुमति देता है और सर्च एपीआई डेवलपर्स को ट्विटर सर्च और ट्रेंड डेटा के साथ बातचीत करने के तरीके प्रदान करता है।[36]

डिजाइन

एपीआई के डिजाइन का इसके उपयोग पर महत्वपूर्ण प्रभाव पड़ता है।[4] सबसे पहले, प्रोग्रामिंग इंटरफेस का डिजाइन सॉफ्टवेयर आर्किटेक्चर के एक महत्वपूर्ण हिस्से का प्रतिनिधित्व करता है, जो सॉफ्टवेयर के एक जटिल टुकड़े का संगठन है।[37] सूचना छिपाने का सिद्धांत मॉड्यूल के कार्यान्वयन विवरण को छिपाकर मॉड्यूलर प्रोग्रामिंग को सक्षम करने के रूप में प्रोग्रामिंग इंटरफेस की भूमिका का वर्णन करता है ताकि मॉड्यूल के उपयोगकर्ताओं को मॉड्यूल के अंदर की जटिलताओं को समझने की आवश्यकता न हो।[38] पिछले अंतर्निहित सिद्धांत के अलावा, एपीआई की उपयोगिता को मापने के लिए अन्य मेट्रिक्स में कार्यात्मक दक्षता, समग्र शुद्धता और नौसिखियों के लिए सीखने की क्षमता जैसे गुण सम्मिलित हो सकते हैं।[39] एपीआई डिजाइन करने का एक सीधा और प्रायः अपनाया जाने वाला तरीका नीलसन के अनुमानी मूल्यांकन दिशानिर्देशों का पालन करना है। फ़ैक्टरी विधि पैटर्न भी उनके पुन: प्रयोज्य प्रकृति के कारण एपीआई को डिजाइन करने में विशिष्ट है।[40] इस प्रकार, एक एपीआई का डिज़ाइन केवल उन उपकरणों को प्रदान करने का प्रयास करता है जिनकी उपयोगकर्ता अपेक्षा करता है।[4]