Jump to content

Application Programming Interface (API)

Վիքիպեդիայից՝ ազատ հանրագիտարանից
Application Programming Interface (API)
գիտական բնագավառ, մասնագիտություն, հետազոտության թեմա Խմբագրել Wikidata
ԵնթակատեգորիաՄիջերես, Համակարգչային պլատֆորմ, հաղորդակարգ Խմբագրել Wikidata
ԿիրառությունըԻնկապսուլյացիա (ծրագրավորում) Խմբագրել Wikidata
Թեմայով վերաբերում էինֆորմատիկա, Ծրագրային ապահովման ճարտարագիտություն Խմբագրել Wikidata
Գործունեության հմտություններինֆորմատիկա, ծրագրավորում, ծրագրային ապահովման մշակում Խմբագրել Wikidata
Օգտագործողծրագրավորող Խմբագրել Wikidata

Application Programming Interface (API) այն եղանակն, որով երկու կամ ավելի համակարգչային ծրագրեր կամ բաղադրիչներ կարող են շփվել միմյանց հետ։ Դա ծրագրային միջերեսի տեսակ է, որը ծառայություն է առաջարկում այլ ծրագրային մասերի համար[1]։ API-ի կառուցվածքը կամ օգտագործման ուղեցույցը կոչվում է API առանձնահատկություն (API specification)։ Հաշվարկային համակարգը, որը համապատասխանում է այս ստանդարտին, ասվում է, որ այն իրականացնում է կամ բացահայտում է API։ API տերմինը կարող է վերաբերվել կամ հատուկ ստանդարտին, կամ դրա իրականացմանը։ Մինչդեռ համակարգի օգտատիրոջ միջերեսը թելադրում է, թե ինչպես են վերջին օգտվողները փոխազդում տվյալ համակարգի հետ, ապա նրա API-ն թելադրում է, թե ինչպես գրել կոդ, որն օգտվում է այդ համակարգի հնարավորություններից:

ՆԱՍԱ-ի կողմից գրված Web API փաստաթղթերի էկրանային պատկերը, որը ցույց է տալիս APOD-ի օգտագործումը։

Ի տարբերություն օգտատիրոջ միջերեսի, որը համակարգիչը միացնում է մարդուն, կիրառական ծրագրավորման միջերեսը միացնում է համակարգիչները կամ ծրագրային ապահովման մասերը միմյանց հետ: Այն նախատեսված չէ ուղղակիորեն օգտագործելու այլ անձի (վերջնական օգտագործողի) կողմից, բացառությամբ համակարգչային ծրագրավորողի, ով այն ներառում է ծրագրային ապահովման մեջ: API-ն հաճախ կազմված է տարբեր մասերից, որոնք գործում են որպես գործիքներ կամ ծառայություններ, որոնք հասանելի են ծրագրավորողին: Ծրագիրը կամ ծրագրավորողը, որն օգտագործում է այս մասերից մեկը, կանչում է է API-ի այդ հատվածը: API-ն կազմող զանգերը հայտնի են նաև որպես ենթածրագրեր, մեթոդներ, հարցումներ կամ վերջնակետեր: API-ի հստակեցումը սահմանում է այս կանչեը, ինչը նշանակում է, որ այն բացատրում է, թե ինչպես օգտագործել կամ իրականացնել դրանք:

API-ների նպատակներից մեկը համակարգի աշխատանքը ներքին մանրամասներից թաքցնելն է, և ցուցադրել միայն այն մասերը, որոնք ծրագրավորողին օգտակար են, պահպանելով դրանք համատեղելի, նույնիսկ եթե ներքին մանրամասները հետագայում փոխվեն։ API-ն կարող է հարմարեցված լինել հատուկ երկու համակարգերի համար, կամ կարող է լինել ընդհանուր ստանդարտ, որը թույլ է տալիս բազմաթիվ համակարգերի միջև փոխազդեցություն։

Կան API-ներ ծրագրավորման լեզուների, ծրագրային գրադարանների, համակարգչային օպերացիոն համակարգերի և համակարգչային սարքավորումների համար։ API-ները ծագել են 1940-ականներին, սակայն տերմինը չի առաջացել մինչ 1960-ականներ և 1970-ականներ։ Տեխնոլոգիական աշխարհի ներկա օգտագործումը հաճախ վերաբերում է Վեբ API-ներին[2], որոնք թույլ են տալիս շփում համակարգչների միջև, որոնք միացված են Ինտերնետին։ API-ների վերջին զարգացումները հանգեցրել են միկրոբծարարքների (microservices) աճին, որոնք թուլորեն կապված ծառայություններ են՝ հասանելի հանրային API-ների միջոցով[3]։

API-ները պետք է ունենան տարբերակներ։ Կան երկու հիմնական տարբերակման ռազմավարություններ[4]՝

  1. Տարբերակման ներքին՝ URL-ի միջոցով․ այս ռազմավարությունը ներառում է տարբերակման տեղեկությունները API-ի URL-ում: Օրինակ, տարբերակը կարող է ընդգրկվել URL-ի մեջ որպես մաս, ինչպես օրինակ՝ api.example.com/v1/resource կամ api.example.com/v2/resource։
  2. Անմիջական տարբերակի ռազմավարություն. այս ռազմավարությունը թույլ է տալիս կատարել ցանկացած փոփոխություններ։ Սա հարմար է բարդ հավելվածների և բարդ փոփոխությունների համար։

Այս ռազմավարությունները օգնում են ծրագրավորողներին և օգտագործողներին ապահովել համատեղելիություն և վերահսկել տարբերակի փոփոխությունները API-ի հետ աշխատելիս։

Ծրագրեր կառուցելիս API-ն պարզեցնում է ծրագրավորումը՝ վերացականացնելով հիմքում ընկած իրականացումը և բացահայտելով միայն մշակողին անհրաժեշտ օբյեկտները կամ գործողությունները: Օրինակ, էլեկտրոնային փոստի հաճախորդի գրապայմանական միջերեսը կարող է տրամադրել կոճակ, որը կատարում է բոլոր քայլերը նոր էլեկտրոնային փոստերի ստացման և ընդգծման համար, մինչդեռ ֆայլերի մուտք/ելքի API-ն կարող է տրամադրել ծրագրավորողին ֆունկցիա, որը պատճենում է ֆայլը մեկ վայրից մյուսը՝ առանց պահանջելու, որ մշակողը հասկանա ֆայլային համակարգի գործողությունները, որոնք կատարվում են հետևում[5]։

Տերմինի պատմություն

[խմբագրել | խմբագրել կոդը]
1978 թվականի դիագրամ, որն առաջարկում է ընդլայնել API-ի գաղափարը՝ դառնալով ընդհանուր ծրագրավորման ինտերֆեյս՝ միայն կիրառական ծրագրերից դուրս[6]։

API տերմինը սկզբնական շրջանում նկարագրվել է միայն վերջնական օգտագործողի ծրագրերի համար նախատեսված միջերես, որոնք հայտնի էին որպես կիրառման ծրագրեր (application programs): Այս ծագումը դեռևս արտահայտված է «Application Programming Interface» անվանման մեջ։ Այսօր տերմինը ավելի լայն իմաստ ունի՝ ներառելով նաև օգտակար ծրագրեր և նույնիսկ սարքավորումների միջերեսներ[7]։

1940-ականներ և 1950-ականներ

[խմբագրել | խմբագրել կոդը]

API-ի գաղափարը շատ ավելի հին է, քան բուն տերմինը: Բրիտանացի համակարգչային գիտնականներ Մորիս Ուիլքսը և Դեյվիդ Ուիլերը 1940-ականներին աշխատել են մոդուլային ծրագրային գրադարանի վրա EDSAC-ի՝ վաղ համակարգչի համար: Այս գրադարանի ենթածրագրերը պահվել են ծակոտժապավենի վրա, որը կազմակերպված է եղել փաստաթղթերի պահարանում: Այն պարունակել է նաև այն, ինչ Ուիլքսը և Ուիլերը անվանում էին «գրադարանային գրացուցակ» յուրաքանչյուր ենթածրագրի վերաբերյալ նշումների և այն ծրագրի մեջ ներառելու մասին, գրադարանը հիմա կոչվում է API (կամ API հստակեցում կամ API փաստաթուղթ), քանի որ այն հրահանգում է ծրագրավորողին, թե ինչպես օգտագործել (կամ «կանչել») յուրաքանչյուր ենթածրագիր, որն անհրաժեշտ է ծրագրավորողին[8]։

Ուիլկսի և Ուիլերի 1951 թվականի «The Preparation of Programs for an Electronic Digital Computer» գիրքը պարունակում է առաջին հրատարակված API առանձնահատկությունը։ Ջոշուա Բլոխը գտնում է, որ Ուիլքսը և Ուիլերը «թաքնված կերպով հայտնագործել են» API-ն, քանի որ այն ավելի շատ հայտնաբերված, քան հորինված հայեցակարգ է[9]։

Չնայած այն մարդիկ, ովքեր հորինել են API տերմինը, ծրագրային ապահովում են իրականացրել Univac 1108-ի վրա, նրանց API-ի նպատակն է եղել հնարավոր դարձնել ապարատային անկախ ծրագրեր[10]։

1960-ականներ և 1970-ականներ

[խմբագրել | խմբագրել կոդը]

«Կիրառական ծրագրի միջերես» տերմինը (ծրագրավորման բառի փոխարեն՝ ծրագիր) առաջին անգամ արձանագրվել է 1968 թվականին AFIPS կոնֆերանսի ժամանակ ներկայացված «Տվյալների կառուցվածքներ և տեխնիկա հեռավոր համակարգչային գրաֆիկայի համար» կոչվող աշխատության մեջ[11][12]։ Այս հոդվածի հեղինակներն օգտագործել են տերմինը՝ նկարագրելու հավելվածի (այս դեպքում գրաֆիկական ծրագրի) փոխազդեցությունը համակարգչային համակարգի մնացած մասերի հետ: Հետևողական կիրառական միջերեսը (կազմված Ֆորտրան ենթածրագրային կանչերից) նախատեսված է եղել ծրագրավորողին ազատելու գրաֆիկական ցուցադրման սարքի յուրահատկություններից և ապահովելու սարքաշարի անկախությունը, եթե համակարգիչը կամ էկրանը փոխարինվեին[13]։

Տերմինը տվյալների բազա է ներմուծվել Քրիստաֆոր Դեյթի կողմից[14] 1974 թվականին «Հարաբերական և ցանցային մոտեցումներ. կիրառական ծրագրավորման միջերեսի համեմատություն» կոչվող հոդվածում[15]։ API-ն դարձել է տվյալների բազայի կառավարման համակարգերի ANSI/SPARC շրջանակի մի մասը: Այս շրջանակը վերաբերվում էր հավելվածի ծրագրավորման միջերեսին առանձին այլ միջերեսներից, ինչպիսին է հարցման միջերեսը: Տվյալների բազայի մասնագետները 1970-ականներին նկատել են, որ այս տարբեր միջերեսները կարող են համակցվել. բավականաչափ հարուստ կիրառական միջերեսը կարող է աջակցել նաև մյուս միջերեսներին[16]։

Այս դիտարկումը հանգեցրել է այն API-ների ստեղծմանը, որոնք աջակցում էին բոլոր տեսակի ծրագրավորմանը։

1990 թվականին տեխնոլոգ Մալամուդը API-ն սահմանել է որպես «ծրագրավորողին հասանելի ծառայությունների հավաքածու, որը կատարում է որոշակի առաջադրանքներ»[17]։

API-ի գաղափարը կրկին ընդլայնվել է հեռակա ընթացակարգերի կանչերի և Վեբ API-ների բախմամբ։ Համակարգչային ցանցերի տարածմամբ 1970-ականներին և 1980-ականներին, ծրագրավորողները ցանկացել են կանչել գրադարաններ, որոնք գտնվում էին ոչ միայն իրենց տեղական համակարգիչներում, այլ նաև այլ վայրերում գտնվող համակարգիչներում։ Այս հեռակա ընթացակարգերի կանչերը հատկապես լավ աջակցություն են ստացել Java լեզվի կողմից։ 1990-ականներին, ինտերնետի տարածման հետ, ստանդարտներ, ինչպիսիք են CORBA, COM և DCOM, մրցում էին՝ դառնալով API ծառայությունները ցուցադրելու ամենատարածված եղանակը[18]։

Ռոյ Ֆիլդինգի 2000 թվականի դիսերտացիան՝ «Աճարային ոճեր և ցանցային ծրագրային ճարտարապետությունների նախագծում» UC Irvine-ում, նկարագրեց Ներկայացուցչական վիճակների փոխանցում (REST) և ներկայացրեց «ցանցային ծրագրավորման միջերես» գաղափարը, որը Ֆիլդինգը հակադրում էր ավանդական «գրադարանային» API-ներին[19]։ XML և JSON Web API-ների լայնածավալ կոմերցիոն ընդունումը սկսվեց 2000 թվականին և շարունակվում է 2022 թվականին։ Այսպիսով, Web API-ն այժմ API տերմինի ամենատարածված իմաստն է[2]։

Թիմ Բերներս-Լիի կողմից 2001 թվականին առաջարկած Սեմանտիկ Վեբը ներառել է «սեմանտիկ API-ներ», որոնք վերաձևում են API-ն որպես բաց, բաշխված տվյալների ինտերֆեյս, այլ ոչ թե ծրագրային վարքագծի ինտերֆեյս[20]։ Նեղ տեսակի ինտերֆեյսները դարձել է ավելի տարածված, քան բացերը, սակայն API-ն որպես տվյալների ինտերֆեյսի գաղափարը արմատավորվել է։ Քանի որ վեբ API-ներ լայնորեն օգտագործվում են տարբեր տեսակի տվյալներ փոխանակելու համար, API-ն դարձել է լայն հասկացություն, որը նկարագրում է ինտերնետում տեղի ունեցող շատ հաղորդակցություններ։[18] Այս կերպ օգտագործվելուց, API տերմինը մասամբ համընկնում է հաղորդակցման պրոտոկոլի տերմինի հետ։

Գրադարաններ և շրջանակներ

[խմբագրել | խմբագրել կոդը]

Ծրագրային գրադարանի հետ կապված միջերեսը API-ի մի տեսակ է։ API-ն նկարագրում և սահմանում է «հնարավոր վարքագիծը» (այսինքն՝ առանձնահատկություն), մինչդեռ գրադարանն այդ կանոնների հավաքածուի «իրական իրականացումն» է։

Մեկ API կարող է ունենալ մի քանի իրականացումներ (կամ որևէ մեկի չունենալ, լինելով աբստրակտ) տարբեր գրադարանների ձևով, որոնք կիսում են նույն ծրագրավորման միջերեսը։

API-ի և նրա իրականացման բաժանումը կարող է թույլ տալ, որ մեկ լեզվով գրված ծրագրերը օգտագործեն այլ լեզվով գրադրված գրադարաններ։ Օրինակ, քանի որ Scala-ն և Java-ն համատեղելի բայթկոդ են վերածվում, Scala-ի մշակողները կարող են օգտվել ցանկացած Java API-ից[21]։

API-ի օգտագործումը կարող է տատանվել կախված ծրագրավորման լեզվի տեսակից։ Օրինակ, Lua-ի նման պրոցեդուրալ լեզվի համար API-ն կարող է հիմնականում պարունակել հիմնարար ընթացակարգեր կոդի իրականացնելու, տվյալները կառավարելու կամ սխալներ շտկելու համար, մինչդեռ Java-ի նման օբյեկտ-առարկայական լեզվի API-ն կտրամադրի դասերի և դրանց մեթոդների նկարագրություն[22][23]։ Հիրումի օրենքը նշում է, որ «API-ի բավականաչափ մեծ թվով օգտատերերով, չի կարևորում, թե ինչ ես խոստանում պայմանագրում՝ ձեր համակարգի բոլոր դիտվող վարքագծերը ինչ-որ մեկի կողմից կախված կլինեն»[24]։ Միջդեռ, մի շարք ուսումնասիրություններ ցույց են տալիս, որ API օգտագործող մեծամասնության դեպքում կիրառվող API-ի փոքր մասն է օգտագործվում[25]։

Մեկ լեզվի առանձնահատկություններն ու հնարավորությունները քարտեզագրելով մեկ այլ լեզվով ներդրված ինտերֆեյսի հետ՝ լեզվական կապը թույլ է տալիս մեկ լեզվով գրված գրադարանին կամ ծառայությանը օգտագործել մեկ այլ լեզվով մշակելիս։

SWIG և F2PY (Fortran-ից Python-ի միջերեսի ստեղծիչ) նման գործիքները հեշտացնում են նման միջերեսների ստեղծումը[26]։

API-ն կարող է նաև կապված լինել ծրագրային շրջանակի հետ։ Շրջանակը կարող է հիմնված լինել մի քանի գրադարանների վրա, որոնք իրականացնում են մի քանի API-ներ, բայց API-ի սովորական օգտագործումից տարբեր, շրջանակի մեջ կառուցված վարքագծին հասանելիությունը միջնորդվում է շրջանակի բովանդակությունն նոր դասերով ընդլայնելու միջոցով։

Ի հավելումն, ընդհանուր ծրագրի հոսքը կարող է դուրս լինել զանգող կողմի վերահսկողությունից և գտնվել շրջանակի վերահսկողության տակ՝ վերահսկողության հակադարձման կամ նման մեխանիզմի միջոցով[27][28]։

Օպերացիոն համակարգեր

[խմբագրել | խմբագրել կոդը]

API-ն կարող է սահմանել հավելվածի և օպերացիոն համակարգի միջերեսը[29]։ POSIX-ը, օրինակ, տրամադրում է API-ի ընդհանուր բնութագրերի մի շարք, որոնց նպատակն է հնարավորություն տալ POSIX համապատասխանող օպերացիոն համակարգի համար գրված հավելվածի կոմպիլյատորի մեկ այլ POSIX համապատասխան օպերացիոն համակարգի համար:

Լինուքսը և Berkeley Software Distribution-ը օպերացիոն համակարգերի օրինակներ են, որոնք իրականացնում են POSIX API-ները[30]։

Մայքրոսոֆթը մեծ հավատարմություն է ցուցաբերել հետընթաց-համատեղելի API-ին, հատկապես իր Windows API (Win32) գրադարանում, այնպես որ ավելի հին հավելվածները կարող են աշխատել Windows-ի նոր տարբերակների վրա՝ օգտագործելով գործարկվող հատուկ պարամետրը, որը կոչվում է «Համատեղելիության ռեժիմ»[31]։

API-ն տարբերվում է հավելվածի երկուական ինտերֆեյսից (ABI) նրանով, որ API-ն հիմնված է սկզբնական կոդերի վրա, մինչդեռ ABI-ն՝ երկուական: Օրինակ, POSIX-ը տրամադրում է API-ներ, մինչդեռ Լինքուքս ստանդարտ բազան տրամադրում է ABI[32] [33]։

Հեռավոր API-ներ

[խմբագրել | խմբագրել կոդը]

Հեռավոր API-ները թույլ են տալիս մշակողներին կառավարել հեռավոր ռեսուրսներ հաղորդակցման պրոտոկոլների միջոցով, որոնք որոշակի ստանդարտներ են հաղորդակցության համար, որոնք թույլ են տալիս տարբեր տեխնոլոգիաների աշխատել միասին, անկախ լեզվից կամ հարթակից։ Օրինակ, Java Database Connectivity API-ն թույլ է տալիս մշակողներին հարցումներ անել տարբեր տեսակի տվյալների բազաների նկատմամբ նույն ֆունկցիաների միջոցով, մինչդեռ Java remote method invocation API-ն օգտագործում է Java Remote Method Protocol-ը՝ հեռավոր գործողությունների կանչման համար, որոնք, սակայն, մշակողի համար թվաբառարանային են թվում։[34][35]

Հետևաբար, հեռավոր API-ները օգտակար են օբյեկտի կողմնորոշված ծրագրավորման մեջ օբյեկտի վերացականությունը պահպանելու համար. մեթոդի կանչը, որը կատարվում է լոկալ պրոքսի օբյեկտի վրա, կանչում է համապատասխան մեթոդը հեռավոր օբյեկտի վրա՝ օգտագործելով հեռակառավարման արձանագրությունը և ստանում է արդյունքը, որը կօգտագործվի տեղում որպես վերադարձի արժեք:

Պրոքսի օբյեկտի փոփոխությունը հանգեցնում է նաև հեռավոր օբյեկտի համապատասխան փոփոխությանը[36]։

Վեբ API-ները ծառայություն են, որը հասանելի է հաճախորդի սարքերից (բջջային հեռախոսներ, դյուրակիր համակարգիչներ և այլն) դեպի վեբ սերվեր ՝ օգտագործելով Hypertext Transfer Protocol (HTTP): Հաճախորդի սարքերը հարցում են ուղարկում HTTP հարցման ձևով և պատասխան հաղորդագրությունով, սովորաբար, JavaScript Object Notation ( JSON ) կամ Extensible Markup Language ( XML) ձևաչափով: Մշակողները սովորաբար օգտագործում են վեբ API-ներ՝ այդ սերվերից տվյալ սերվերի որոշակի հավաքածուի համար հարցումներ անելու համար:

Սոցիալական մեդիայի տարածքում վեբ API-ները թույլ են տվել վեբ համայնքներին հեշտացնել բովանդակության և տվյալների փոխանակումը համայնքների և հավելվածների միջև: Այս կերպ, մեկ վայրում դինամիկ կերպով ստեղծվող բովանդակությունը կարող է տեղադրվել և թարմացվել համացանցում մի քանի վայրերում[37]։ Օրինակ՝ Twitter-ի REST API-ն ծրագրավորողներին թույլ է տալիս մուտք գործել Twitter-ի հիմնական տվյալներ, իսկ Search API-ն ծրագրավորողների համար տրամադրում է մեթոդներ՝ փոխազդելու Twitter-ի որոնման և միտումների տվյալների հետ[38]։

API-ի նախագծումը էական ազդեցություն ունի դրա օգտագործման վրա[39]։ Նախևառաջ, ծրագրավորման ինտերֆեյսների ձևավորումը ներկայացնում է ծրագրային ապահովման ճարտարապետության կարևոր մասը, ծրագրային ապահովման բարդ մասի կազմակերպումը[40]։ Տեղեկատվության թաքցման սկզբունքը նկարագրում է ծրագրավորման միջերեսների դերը որպես մոդուլային ծրագրավորման հնարավորություն՝ թաքցնելով մոդուլների իրականացման մանրամասները, որպեսզի մոդուլների օգտագործողները չհասկանան մոդուլների ներսում առկա բարդությունները[41]։ Բացի նախորդ հիմքում ընկած սկզբունքից, API-ի օգտագործելիությունը չափելու այլ չափումներ կարող են ներառել այնպիսի հատկություններ, ինչպիսիք են ֆունկցիոնալ արդյունավետությունը, ընդհանուր ճիշտությունը և նորեկների համար սովորելիությունը[42]։ Ֆաբրիկային մեթոդի օրինաչափությունը նույնպես բնորոշ է API-ների նախագծման մեջ՝ դրանց բազմակի օգտագործման բնույթի պատճառով[43]։ Այսպիսով, API-ի նախագծումը փորձում է տրամադրել միայն այն գործիքները, որոնք օգտատերը ակնկալում է[39]։

Համաժամանակյա ընդդեմ անհամաժամանակյա

[խմբագրել | խմբագրել կոդը]

Դիմումների ծրագրավորման ինտերֆեյսը (API) կարող է լինել համաժամանակյա կամ անհամաժամանակյա։ Համաժամանակյա API կանչը դիզայնի այն օրինաչափությունն է, որտեղ կանչի տեղը արգելափակվում է, մինչ սպասում է կանչված կոդի ավարտին[44]։ Այն դեպքում, երբ անհամաժամանակյա API կանչ կա, կանչի տեղը չի արգելափակվում, մինչ սպասում է կանչված կոդի ավարտին, և փոխարենը կանչողը տեղեկացվում է, երբ պատասխանը հասնում է։

Թողարկման ձևեր

[խմբագրել | խմբագրել կոդը]

API-ները տեխնոլոգիական ընկերությունների ինտեգրման ավելի տարածված եղանակներից են: API-ներ տրամադրողները և օգտագործողները համարվում են բիզնես էկոհամակարգի անդամներ[45]։

API-ի թողարկման հիմնական ձևերն են[46]՝

  • Մասնավոր․ API-ն նախատեսված է միայն ընկերության ներքին օգտագործման համար:
  • Գործընկեր․ API-ն կարող են օգտագործել միայն կոնկրետ բիզնես գործընկերներ: Օրինակ, վարձակալության համար նախատեսված մեքենաները, ինչպիսիք են Uber-ը և Lyft-ը, թույլ են տալիս հաստատված երրորդ կողմի մշակողներին ուղղակիորեն պատվիրել երթուղիներ իրենց հավելվածներից: Սա թույլ է տալիս ընկերություններին իրականացնել որակի վերահսկողություն՝ ճշտելով, թե որ հավելվածներն ունեն մուտք դեպի API և նրանց տրամադրում է լրացուցիչ եկամուտների հոսք[47][48]։
  • Հանրային. API-ն հասանելի է հանրության կողմից օգտագործման համար: Օրինակ, Մայքրոսոֆթը հրապարակում է Windows API-ն, իսկ Էփլը թողարկում է իր API Cocoa-ն, որպեսզի ծրագրակազմը գրվի իրենց հարթակների համար: Ոչ բոլոր հանրային API-ներն են սովորաբար հասանելի բոլորի համար: Օրինակ՝ համացանցային ծառայություններ մատուցողները, ինչպիսիք են Cloudflare-ը կամ Voxility-ը, օգտագործում են RESTful API-ներ՝ թույլ տալու հաճախորդներին և վերավաճառողներին մուտք գործել իրենց ենթակառուցվածքի մասին տեղեկատվությունը, DDoS վիճակագրությունը, ցանցի կատարողականը կամ վահանակի կառավարումը[49]։ Նման API-ների հասանելիությունը տրվում է կա՛մ «API-ի նշաններով», կա՛մ հաճախորդի կարգավիճակի վավերացումներով[50]։

Հանրային API-ի հետևանքները

[խմբագրել | խմբագրել կոդը]

Հանրային API-ի համար կարևոր գործոններից մեկը դրա «ինտերֆեյսի կայունությունն»է։ API-ին փոփոխություններ կատարելը՝ օրինակ, ֆունկցիայի կանչին նոր պարամետրեր ավելացնելը, կարող է խախտել համապատասխանությունը այն հաճախորդների հետ, որոնք կախված են այդ API-ից[51]։

Երբ հրապարակայնորեն ներկայացված API-ի մասերը ենթակա են փոփոխման և, հետևաբար, կայուն չեն, որոշակի API-ի այդպիսի մասերը պետք է բացահայտորեն փաստաթղթավորվեն որպես «անկայուն»: Օրինակ, Գուգլ Guava գրադարանում այն մասերը, որոնք համարվում են անկայուն, և որոնք կարող են շուտով փոխվել, նշվում են Java-յի@Betaմեկնաբանությունոբ[52]։

Հանրային API-ն երբեմն կարող է իր որոշ մասեր հայտարարել որպես հնացած կամ չեղյալ հայտարարել: Սա սովորաբար նշանակում է, որ API-ի մի մասը պետք է համարվի որպես թեկնածու հեռացման կամ փոփոխման հետ անհամատեղելի ձևով: Հետևաբար, այս փոփոխությունները ծրագրավորողներին թույլ են տալիս հեռանալ API-ի այն մասերից, որոնք հետագայում կհեռացվեն կամ չեն աջակցվի[53]։

2020 թվականի փետրվարի 19-ին Akamai-ն հրապարակել է իրենց տարեկան «Ինտերնետի վիճակ» զեկույցը, որը ցույց տվեց կիբեռհանցագործությունների աճող միտումը հանրային API պլատֆորմների դեմ՝ ֆինանսական ծառայություններում ամբողջ աշխարհում։ 2017 թվականի դեկտեմբերից մինչև 2019 թվականի նոյեմբեր Akamai-ն հրապարակել է 85.42 միլիարդ հավատարմագրերի խախտման հարձակումներ։ Մոտ 20%-ը, կամ 16.55 միլիարդ, ուղղված են եղել API վերջնակետերի սահմանված անուններին։ Դրանցից 473.5 միլիոնը ուղղված էր ֆինանսական ծառայությունների ոլորտի կազմակերպություններին[54]։

API փաստաթղթավորումը նկարագրում է API-ի առաջարկած ծառայությունները և դրանց օգտագործման եղանակները, նպատակ ունենալով ընդգրկել այն ամենը, ինչ անհրաժեշտ է հաճախորդին գործնական նպատակներով:

Փաստաթղթավորումը շատ կարևոր է API-ով աշխատող ծրագրերի մշակման և պահպանման համար[55]։ API փաստաթղթավորումը ավանդաբար գտնվում է փաստաթղթավորման ֆայլերում, սակայն նաև կարելի է գտնել սոցիալական մեդիայում, ինչպիսիք են բլոգները, ֆորումները և հարց ու պատասխանի կայքերը[56]։

Ավանդական փաստաթղթավորման ֆայլերը հաճախ ներկայացվում են փաստաթղթավորման համակարգերի միջոցով, ինչպիսիք են Javadoc կամ Pydoc, որոնք ունեն կայուն տեսք և կառուցվածք: Այնուամենայնիվ, փաստաթղթությունում ներառվող բովանդակության տեսակները տարբեր են API-ներից[57]։

Ցուցակի հասկացողության համար, API փաստաթղթավորումը կարող է ներառել API-ում հասկացությունների և մեթոդների նկարագրություններ, ինչպես նաև «լիարժեք օգտագործման դեպքեր, կոդի նմուշներ, դիզայնի պատճառաբանություններ, կատարողականի քննարկումներ և պայմանագրեր», սակայն API ծառայությունների իրականացման մանրամասները սովորաբար բաց թողնվում են:

REST API-ի վերակացու փաստաթղթավորումը կարող է ավտոմատ կերպով ստեղծվել OpenAPI փաստաթղթից, որն է մեքենա ընթերցվող տեքստային ֆայլ, որն օգտագործում է OpenAPI Օրենքում սահմանված նախանշված ձևաչափ և սինտաքս: OpenAPI փաստաթուղթը սահմանում է հիմնական տեղեկություններ, ինչպիսիք են API-ի անունը և նկարագրությունը, ինչպես նաև նկարագրում է գործողությունները, որոնք API-ն տրամադրում է[58]։

API-ի փաստաթղթերը կարող են հարստացվել մետատվյալներով, ինչպիսիք են Java ծանոթագրությունները: Այս մետատվյալները կարող են օգտագործվել կոմպիլյատորի, գործիքների և գործարկման ժամանակի միջավայրի կողմից՝ հատուկ վարքագծերը կամ հատուկ մշակումը իրականացնելու համար[59]։

API-ների հեղինակային իրավունքի պաշտպանության վերաբերյալ վեճ

[խմբագրել | խմբագրել կոդը]

2010 թվականին Oracle Corporation-ը դատի է տվել Գուգլին՝ Անդրոիդ օպերացիոն համակարգում ներդրված Ջավայի նոր ներդրումը տարածելու համար[60]։ Գուգլը Java API-ն վերարտադրելու որևէ թույլտվություն չի ստացել, թեև թույլտվություն է տրվել նմանատիպ OpenJDK նախագծին: Գուգլը դիմել է Oracle-ին իրենց API-ի լիցենզիայի շուրջ բանակցություններ վարելու համար, սակայն մերժվել էր վստահության խնդիրների պատճառով: Չնայած անհամաձայնությանը, Գուգլն ամեն դեպքում նախընտրել է օգտագործել Oracle-ի կոդը:

Oracle-ի պահանջը ընդունելը նշանակում է թույլ տալ, որ յուրաքանչյուրը հեղինակային իրավունքներ ստանա մեկ ծածկագրի տարբերակի համար, որը իրականացնում է հրամանների համակարգ, և այդպիսով արգելել մյուսներին գրել իրենց տարբերակները՝ նույն կամ մասնակի հրամանները կատարելու համար[61][62]։

Որոշումը չեղարկվել է 2014 թվականին՝ Դաշնային շրջանի վերաքննիչ դատարան դիմելու հիման վրա, թեև այն հարցը, թե արդյոք API-ների նման օգտագործումը արդար օգտագործում է, մնցել է չլուծված[63][64]։

2016 թվականին, երկու շաբաթ տևած դատավարությունից հետո, ատենակալները որոշել են, որ Գուգլի Java API-ի կրկնօգտագործումը արդար օգտագործում է, բայց Oracle Corporation բողոքարկել է որոշումը[65]։ Oracle Corporation-ը հաղթել է և Circuit-իAppeals Court-ը որոշել է, որ Գուգլի API-ների օգտագործումը չի համապատասխանում արդար օգտագործման պահանջներին[66]։ 2019 թվականին Գուգլը բողոքել է ԱՄՆ-ի Գերագույն դատարան՝ հեղինակային իրավունքների և արդար օգտագործման վերաբերյալ վճիռների դեմ, և Գերագույն դատարանը համաձայնել է ուսումնասիրել գործը։ COVID-19 պանդեմիայի պատճառով դատական լսումները հետաձգվել են մինչև 2020 թվականի հոկտեմբեր[67]։

Գործը վճռվել է Գերագույն դատարանի կողմից՝ հօգուտ Գուգլի՝ 6-2 որոշմամբ։ Դատավոր Սթիվեն Բրեյերը ներկայացրել է դատարանի կարծիքը և նշել,որ ՝ «հայտարարող ծածկագիրը, եթե ընդհանրապես ենթակա է հեղինակային իրավունքի, ավելին է, քան հեղինակային իրավունքի հիմքում ընկած համակարգչային ծրագրերի մեծ մասը»[68][69]։

Ծանոթագրություններ

[խմբագրել | խմբագրել կոդը]
  1. Reddy, Martin (2011). API Design for C++. Elsevier Science. էջ 1. ISBN 9780123850041. Արխիվացված օրիգինալից 2023-04-15-ին. Վերցված է 2023-03-21-ին.
  2. 2,0 2,1 Lane, Kin (October 10, 2019). «Intro to APIs: History of APIs». Postman (ամերիկյան անգլերեն). Արխիվացված օրիգինալից September 11, 2020-ին. Վերցված է September 18, 2020-ին. «When you hear the acronym "API" or its expanded version "Application Programming Interface", it is almost always in reference to our modern approach, in that we use HTTP to provide access to machine readable data in a JSON or XML format, often simply referred to as "Web APIs". APIs have been around almost as long as computing, but modern Web APIs began taking shape in the early 2000s.»
  3. Wood, Laura (2021-08-25). «Global Cloud Microservices Market (2021 to 2026)». businesswire.com (ամերիկյան անգլերեն). Արխիվացված օրիգինալից 2022-04-08-ին. Վերցված է 2022-03-29-ին.
  4. Designing Web APIs Building APIs That Developers Love. O'Reilly Media. 2018. ISBN 9781492026877.
  5. Clarke, Steven (2004). «Measuring API Usability». Dr. Dobb's. Արխիվացված օրիգինալից 3 March 2022-ին. Վերցված է 29 July 2016-ին.
  6. Database architectures – a feasibility workshop (Report). Washington, DC: U.S. Department of Commerce, National Bureau of Standards. April 1981. էջեր 45–47. hdl:2027/mdp.39015077587742. LCCN 81600004. NBS special publication 500-76. Վերցված է September 18, 2020-ին.
  7. A Brief, Opinionated History of the API (Speech). QCon. San Francisco: InfoQ. August 8, 2018. Արխիվացված օրիգինալից September 22, 2020-ին. Վերցված է September 18, 2020-ին.
  8. (Speech). QCon. San Francisco. August 8, 2018. {{cite speech}}: |access-date= requires |url= (օգնություն); Missing or empty |title= (օգնություն)
  9. Bloch, Joshua (August 8, 2018). (Speech). QCon. San Francisco. {{cite speech}}: |access-date= requires |url= (օգնություն); Missing or empty |title= (օգնություն)
  10. Cotton, Ira W.; Greatorex, Frank S. (December 1968). «Data structures and techniques for remote computer graphics». AFIPS '68: Proceedings of the December 9–11, 1968, Fall Joint Computer Conference. AFIPS 1968 Fall Joint Computer Conference. Vol. I. San Francisco, California: Association for Computing Machinery. էջեր 533–544. doi:10.1145/1476589.1476661. ISBN 978-1450378994. OCLC 1175621908. Արխիվացված օրիգինալից 2020-10-20-ին. Վերցված է 2020-09-19-ին.
  11. «application program interface». Օքսֆորդի անգլերեն բառարան (3-րդ հրատարակություն ed.). Օքսֆորդի համալսարանի հրատարակչություն. սեպտեմբեր, 2015. 
  12. Bloch, Joshua (August 8, 2018). (Speech). QCon. San Francisco. {{cite speech}}: |access-date= requires |url= (օգնություն); Missing or empty |title= (օգնություն)
  13. Cotton, Ira W.; Greatorex, Frank S. (December 1968). Data structures and techniques for remote computer graphics. AFIPS 1968 Fall Joint Computer Conference. Vol. I. San Francisco, California: Association for Computing Machinery. էջեր 533–544. doi:10.1145/1476589.1476661. ISBN 978-1450378994. OCLC 1175621908. Արխիվացված է օրիգինալից 2020-10-20-ին. Վերցված է 2020-09-19-ին.
  14. Date, C. J. (2019). E. F. Codd and Relational Theory: A Detailed Review and Analysis of Codd's Major Database Writings. Lulu.com. էջ 135. ISBN 978-1684705276.
  15. Date, C. J.; Codd, E. F. (January 1975). The relational and network approaches: Comparison of the application programming interfaces. SIGMOD Workshop 1974. Vol. 2. Ann Arbor, Michigan: Association for Computing Machinery. էջեր 83–113. doi:10.1145/800297.811532. ISBN 978-1450374187. OCLC 1175623233.
  16. Database architectures – a feasibility workshop (Report). Washington, DC: U.S. Department of Commerce, National Bureau of Standards. April 1981. էջեր 45–47. LCCN 81600004. NBS special publication 500-76. Վերցված է September 18, 2020-ին.
  17. Carl, Malamud (1990). Analyzing Novell Networks. Van Nostrand Reinhold. էջ 294. ISBN 978-0442003647. Արխիվացված օրիգինալից 2021-01-26-ին. Վերցված է 2020-09-19-ին.
  18. 18,0 18,1 Jin, Brenda; Sahni, Saurabh; Shevat, Amir (2018). Designing Web APIs. O'Reilly Media. ISBN 9781492026877. Արխիվացված օրիգինալից 2023-04-10-ին. Վերցված է 2023-03-21-ին.
  19. Fielding, Roy (2000). Architectural Styles and the Design of Network-based Software Architectures (PhD). University of California, Irvine. Արխիվացված օրիգինալից January 22, 2020-ին. Վերցված է September 18, 2020-ին.
  20. Dotsika, Fefie (August 2010). «Semantic APIs: Scaling up towards the Semantic Web». International Journal of Information Management. 30 (4): 335–342. doi:10.1016/j.ijinfomgt.2009.12.003.
  21. Odersky, Martin; Spoon, Lex; Venners, Bill (10 December 2008). «Combining Scala and Java». artima.com. Արխիվացված օրիգինալից 8 August 2016-ին. Վերցված է 29 July 2016-ին.
  22. de Figueiredo, Luiz Henrique; Ierusalimschy, Roberto; Filho, Waldemar Celes (1994). «The design and implementation of a language for extending applications». TeCGraf Grupo de Tecnologia Em Computacao Grafica: 273–284. CiteSeerX 10.1.1.47.5194. S2CID 59833827. Վերցված է 29 July 2016-ին.
  23. Sintes, Tony (2001-07-13). «Just what is the Java API anyway?». JavaWorld. Արխիվացված օրիգինալից 2020-10-19-ին. Վերցված է 2020-07-18-ին.
  24. Winters, Titus; Tom Manshreck; Hyrum Wright, eds. (2020). Software engineering at Google: lessons learned from programming over time. Sebastopol, CA: O'Reilly Media. ISBN 9781492082798. OCLC 1144086840.
  25. Mastrangelo, Luis; Ponzanelli, Luca; Mocci, Andrea; Lanza, Michele; Hauswirth, Matthias; Nystrom, Nathaniel (2015-10-23). «Use at your own risk: the Java unsafe API in the wild». Proceedings of the 2015 ACM SIGPLAN International Conference on Object-Oriented Programming, Systems, Languages, and Applications. OOPSLA 2015. New York, New York, U.S.: Association for Computing Machinery. էջեր 695–710. doi:10.1145/2814270.2814313. ISBN 978-1-4503-3689-5.
  26. «F2PY.org». F2PY.org. Արխիվացված օրիգինալից 2011-07-04-ին. Վերցված է 2011-12-18-ին.
  27. Fowler, Martin. «Inversion Of Control». Արխիվացված օրիգինալից 2011-01-23-ին. Վերցված է 2011-08-25-ին.
  28. Fayad, Mohamed. «Object-Oriented Application Frameworks». Արխիվացված օրիգինալից 2013-11-05-ին. Վերցված է 2013-11-05-ին.
  29. Lewine, Donald A. (1991). POSIX Programmer's Guide. O'Reilly & Associates, Inc. էջ 1. ISBN 9780937175736. Արխիվացված օրիգինալից 22 August 2016-ին. Վերցված է 2 August 2016-ին.
  30. West, Joel; Dedrick, Jason (2001). «Open source standardization: the rise of Linux in the network era» (PDF). Knowledge, Technology & Policy. 14 (2): 88–112. doi:10.1007/PL00022278. S2CID 46082812. Արխիվացված (PDF) օրիգինալից 27 August 2016-ին. Վերցված է 2 August 2016-ին.
  31. Microsoft (October 2001). «Support for Windows XP». Microsoft. էջ 4. Արխիվացված է օրիգինալից 2009-09-26-ին.
  32. «LSB Introduction». Linux Foundation. 21 June 2012. Արխիվացված է օրիգինալից 2015-04-02-ին. Վերցված է 2015-03-27-ին.
  33. Stoughton, Nick (April 2005). «Update on Standards» (PDF). USENIX. Արխիվացված (PDF) օրիգինալից 2009-03-27-ին. Վերցված է 2009-06-04-ին.
  34. Bierhoff, Kevin (23 April 2009). API Protocol Compliance in Object-Oriented Software (PDF) (PhD). Carnegie Mellon University. ISBN 978-1-109-31660-5. ProQuest 304864018. Արխիվացված (PDF) օրիգինալից 11 October 2016-ին. Վերցված է 29 July 2016-ին.
  35. Wilson, M. Jeff (2000-11-10). «Get smart with proxies and RMI». JavaWorld. Արխիվացված օրիգինալից 2020-07-20-ին. Վերցված է 2020-07-18-ին.
  36. Henning, Michi; Vinoski, Steve (1999). Advanced CORBA Programming with C++. Addison-Wesley. ISBN 978-0201379273. Վերցված է 16 June 2015-ին.
  37. Parr, Ben (21 May 2009). «The Evolution of the Social Media API». Mashable. Արխիվացված է օրիգինալից Aug 11, 2016-ին. Վերցված է 26 July 2016-ին.
  38. «GET trends/place». Twitter Developer Platform (անգլերեն). Արխիվացված օրիգինալից 2020-06-17-ին. Վերցված է 2020-04-30-ին.
  39. 39,0 39,1 Clarke, Steven (2004). «Measuring API Usability». Dr. Dobb's. Արխիվացված օրիգինալից 3 March 2022-ին. Վերցված է 29 July 2016-ին.
  40. Garlan, David; Shaw, Mary (January 1994). «An Introduction to Software Architecture» (PDF). Advances in Software Engineering and Knowledge Engineering. 1. Արխիվացված (PDF) օրիգինալից 6 May 2021-ին. Վերցված է 8 August 2016-ին – via CMU School of Computer Science.
  41. Parnas, D.L. (1972). «On the Criteria To Be Used in Decomposing Systems into Modules». Communications of the ACM. 15 (12): 1053–1058. doi:10.1145/361598.361623. S2CID 53856438.
  42. Myers, Brad A.; Stylos, Jeffrey (2016). «Improving API usability». Communications of the ACM. 59 (6): 62–69. doi:10.1145/2896587. S2CID 543853.
  43. Brian Ellis, Jeffrey Stylos, and Brad Myers. 2007. "The Factory Pattern in API Design: A Usability Evaluation Արխիվացված 2022-03-21 Wayback Machine". In Proceedings of the 29th international conference on Software Engineering (ICSE '07). IEEE Computer Society, USA, 302–312. doi:10.1109/ICSE.2007.85.
  44. "Synchronous vs. Asynchronous Writes - Packaged Contact Center Enterprise" - Cisco DevNet Արխիվացված 2022-08-03 Wayback Machine.
  45. de Ternay, Guerric (Oct 10, 2015). «Business Ecosystem: Creating an Economic Moat». BoostCompanies. Արխիվացված է օրիգինալից 2016-09-17-ին. Վերցված է 2016-02-01-ին.
  46. Boyd, Mark (2014-02-21). «Private, Partner or Public: Which API Strategy Is Best for Business?». ProgrammableWeb. Արխիվացված օրիգինալից 2016-07-18-ին. Վերցված է 2 August 2016-ին.
  47. Weissbrot, Alison (7 July 2016). «Car Service APIs Are Everywhere, But What's In It For Partner Apps?». AdExchanger. Արխիվացված օրիգինալից 28 July 2020-ին. Վերցված է 14 August 2020-ին.
  48. Weissbrot, Alison (7 July 2016). «Car Service APIs Are Everywhere, But What's In It For Partner Apps?». AdExchanger. Արխիվացված օրիգինալից 28 July 2020-ին. Վերցված է 14 August 2020-ին.
  49. «Cloudflare API v4 Documentation». cloudflare. 25 February 2020. Արխիվացված օրիգինալից 26 February 2020-ին. Վերցված է 27 February 2020-ին.
  50. Liew, Zell (17 January 2018). «Car Service APIs Are Everywhere, But What's In It For Partner Apps». Smashing Magazine. Արխիվացված օրիգինալից 21 February 2020-ին. Վերցված է 27 February 2020-ին.
  51. Shi, Lin; Zhong, Hao; Xie, Tao; Li, Mingshu (2011). «An Empirical Study on Evolution of API Documentation». Fundamental Approaches to Software Engineering. International Conference on Fundamental Approaches to Software Engineering. Lecture Notes in Computer Science. Vol. 6603. էջեր 416–431. doi:10.1007/978-3-642-19811-3_29. ISBN 978-3-642-19810-6. Վերցված է 22 July 2016-ին.
  52. «guava-libraries – Guava: Google Core Libraries for Java 1.6+». Google Project Hosting. 2014-02-04. Արխիվացված է օրիգինալից Mar 26, 2014-ին. Վերցված է 2014-02-11-ին.
  53. Oracle. «How and When to Deprecate APIs». Java SE Documentation. Արխիվացված օրիգինալից 9 April 2016-ին. Վերցված է 2 August 2016-ին.
  54. Takanashi, Dean (19 February 2020). «Akamai: Cybercriminals are attacking APIs at financial services firms». Venture Beat. Արխիվացված օրիգինալից 27 February 2020-ին. Վերցված է 27 February 2020-ին.
  55. Dekel, Uri; Herbsleb, James D. (May 2009). «Improving API Documentation Usability with Knowledge Pushing». Institute for Software Research, School of Computer Science. CiteSeerX 10.1.1.446.4214.
  56. Parnin, Chris; Treude, Cristoph (May 2011). «Measuring API documentation on the web». Web2SE '11: Proceedings of the 2nd International Workshop on Web 2.0 for Software Engineering. էջեր 25–30. doi:10.1145/1984701.1984706. ISBN 9781450305952. S2CID 17751901.
  57. Maalej, Waleed; Robillard, Martin P. (April 2012). «Patterns of Knowledge in API Reference Documentation» (PDF). IEEE Transactions on Software Engineering. Արխիվացված (PDF) օրիգինալից 22 August 2016-ին. Վերցված է 22 July 2016-ին.
  58. «Structure of an OpenAPI Document». OpenAPI Documentation (ամերիկյան անգլերեն). Արխիվացված է օրիգինալից 2022-11-06-ին. Վերցված է 2022-11-06-ին.
  59. «Annotations». Sun Microsystems. Արխիվացված է օրիգինալից 2011-09-25-ին. Վերցված է 2011-09-30-ին..
  60. «Oracle and the End of Programming As We Know It». DrDobbs. 2012-05-01. Արխիվացված օրիգինալից 2012-05-09-ին. Վերցված է 2012-05-09-ին.
  61. «APIs Can't be Copyrighted Says Judge in Oracle Case». TGDaily. 2012-06-01. Արխիվացված օրիգինալից 2012-12-21-ին. Վերցված է 2012-12-06-ին.
  62. «Oracle America, Inc. vs. Google Inc.» (PDF). Wired. 2012-05-31. Արխիվացված (PDF) օրիգինալից 2013-11-04-ին. Վերցված է 2013-09-22-ին.
  63. «Oracle Am., Inc. v. Google Inc., No. 13-1021, Fed. Cir. 2014». Արխիվացված օրիգինալից 2014-10-10-ին.
  64. Rosenblatt, Seth (May 9, 2014). «Court sides with Oracle over Android in Java patent appeal». CNET. Արխիվացված օրիգինալից 2017-04-19-ին. Վերցված է 2014-05-10-ին.
  65. «Google beats Oracle – Android makes "fair use" of Java APIs». Ars Technica. 2016-05-26. Արխիվացված օրիգինալից 2017-01-20-ին. Վերցված է 2016-07-28-ին.
  66. Decker, Susan (March 27, 2018). «Oracle Wins Revival of Billion-Dollar Case Against Google». Bloomberg Businessweek. Արխիվացված օրիգինալից January 9, 2022-ին. Վերցված է March 27, 2018-ին.
  67. vkimber (2020-09-28). «Google LLC v. Oracle America, Inc». LII / Legal Information Institute (անգլերեն). Արխիվացված օրիգինալից 2021-04-15-ին. Վերցված է 2021-03-06-ին.
  68. «Supreme Court of the United States, No. 18–956, GOOGLE LLC, PETITIONER v. ORACLE AMERICA, INC» (PDF). April 5, 2021. Արխիվացված (PDF) օրիգինալից April 5, 2021-ին. Վերցված է April 25, 2021-ին.
  69. «Supreme Court of the United States, No. 18–956, GOOGLE LLC, PETITIONER v. ORACLE AMERICA, INC» (PDF). April 5, 2021. Արխիվացված (PDF) օրիգինալից April 5, 2021-ին. Վերցված է April 25, 2021-ին.

Հետագա ընթերցում

[խմբագրել | խմբագրել կոդը]
  • Taina Bucher (16 November 2013). «Objects of Intense Feeling: The Case of the Twitter API». Computational Culture (3). ISSN 2047-2390. Argues that "APIs are far from neutral tools" and form a key part of contemporary programming, understood as a fundamental part of culture.
  • What is an API? – in the U.S. Supreme Court opinion, Գուգլ v. Oracle 2021, pp. 3–7 – "For each task, there is computer code; API (also known as Application Programming Interface) is the method for calling that 'computer code' (instruction – like a recipe – rather than cooking instruction, this is machine instruction) to be carry out"
  • Maury, Innovation and Change – Cory Ondrejka, February 28, 2014, " ...proposed a public API to let computers talk to each other". (Textise(չաշխատող հղում) URL)

Արտաքին հղումներ

[խմբագրել | խմբագրել կոդը]