Application Programming Interface (API)
From Wikipedia, the free encyclopedia
Remove ads
Application Programming Interface (API) այն եղանակն, որով երկու կամ ավելի համակարգչային ծրագրեր կամ բաղադրիչներ կարող են շփվել միմյանց հետ։ Դա ծրագրային միջերեսի տեսակ է, որը ծառայություն է առաջարկում այլ ծրագրային մասերի համար[1]։ API-ի կառուցվածքը կամ օգտագործման ուղեցույցը կոչվում է API առանձնահատկություն (API specification)։ Հաշվարկային համակարգը, որը համապատասխանում է այս ստանդարտին, ասվում է, որ այն իրականացնում է կամ բացահայտում է API։ API տերմինը կարող է վերաբերվել կամ հատուկ ստանդարտին, կամ դրա իրականացմանը։ Մինչդեռ համակարգի օգտատիրոջ միջերեսը թելադրում է, թե ինչպես են վերջին օգտվողները փոխազդում տվյալ համակարգի հետ, ապա նրա API-ն թելադրում է, թե ինչպես գրել կոդ, որն օգտվում է այդ համակարգի հնարավորություններից:
Ի տարբերություն օգտատիրոջ միջերեսի, որը համակարգիչը միացնում է մարդուն, կիրառական ծրագրավորման միջերեսը միացնում է համակարգիչները կամ ծրագրային ապահովման մասերը միմյանց հետ: Այն նախատեսված չէ ուղղակիորեն օգտագործելու այլ անձի (վերջնական օգտագործողի) կողմից, բացառությամբ համակարգչային ծրագրավորողի, ով այն ներառում է ծրագրային ապահովման մեջ: API-ն հաճախ կազմված է տարբեր մասերից, որոնք գործում են որպես գործիքներ կամ ծառայություններ, որոնք հասանելի են ծրագրավորողին: Ծրագիրը կամ ծրագրավորողը, որն օգտագործում է այս մասերից մեկը, կանչում է է API-ի այդ հատվածը: API-ն կազմող զանգերը հայտնի են նաև որպես ենթածրագրեր, մեթոդներ, հարցումներ կամ վերջնակետեր: API-ի հստակեցումը սահմանում է այս կանչեը, ինչը նշանակում է, որ այն բացատրում է, թե ինչպես օգտագործել կամ իրականացնել դրանք:
API-ների նպատակներից մեկը համակարգի աշխատանքը ներքին մանրամասներից թաքցնելն է, և ցուցադրել միայն այն մասերը, որոնք ծրագրավորողին օգտակար են, պահպանելով դրանք համատեղելի, նույնիսկ եթե ներքին մանրամասները հետագայում փոխվեն։ API-ն կարող է հարմարեցված լինել հատուկ երկու համակարգերի համար, կամ կարող է լինել ընդհանուր ստանդարտ, որը թույլ է տալիս բազմաթիվ համակարգերի միջև փոխազդեցություն։
Կան API-ներ ծրագրավորման լեզուների, ծրագրային գրադարանների, համակարգչային օպերացիոն համակարգերի և համակարգչային սարքավորումների համար։ API-ները ծագել են 1940-ականներին, սակայն տերմինը չի առաջացել մինչ 1960-ականներ և 1970-ականներ։ Տեխնոլոգիական աշխարհի ներկա օգտագործումը հաճախ վերաբերում է Վեբ API-ներին[2], որոնք թույլ են տալիս շփում համակարգչների միջև, որոնք միացված են Ինտերնետին։ API-ների վերջին զարգացումները հանգեցրել են միկրոբծարարքների (microservices) աճին, որոնք թուլորեն կապված ծառայություններ են՝ հասանելի հանրային API-ների միջոցով[3]։
API-ները պետք է ունենան տարբերակներ։ Կան երկու հիմնական տարբերակման ռազմավարություններ[4]՝
- Տարբերակման ներքին՝ URL-ի միջոցով․ այս ռազմավարությունը ներառում է տարբերակման տեղեկությունները API-ի URL-ում: Օրինակ, տարբերակը կարող է ընդգրկվել URL-ի մեջ որպես մաս, ինչպես օրինակ՝
api.example.com/v1/resourceկամapi.example.com/v2/resource։ - Անմիջական տարբերակի ռազմավարություն. այս ռազմավարությունը թույլ է տալիս կատարել ցանկացած փոփոխություններ։ Սա հարմար է բարդ հավելվածների և բարդ փոփոխությունների համար։
Այս ռազմավարությունները օգնում են ծրագրավորողներին և օգտագործողներին ապահովել համատեղելիություն և վերահսկել տարբերակի փոփոխությունները API-ի հետ աշխատելիս։
Remove ads
Նպատակ
Ծրագրեր կառուցելիս API-ն պարզեցնում է ծրագրավորումը՝ վերացականացնելով հիմքում ընկած իրականացումը և բացահայտելով միայն մշակողին անհրաժեշտ օբյեկտները կամ գործողությունները: Օրինակ, էլեկտրոնային փոստի հաճախորդի գրապայմանական միջերեսը կարող է տրամադրել կոճակ, որը կատարում է բոլոր քայլերը նոր էլեկտրոնային փոստերի ստացման և ընդգծման համար, մինչդեռ ֆայլերի մուտք/ելքի API-ն կարող է տրամադրել ծրագրավորողին ֆունկցիա, որը պատճենում է ֆայլը մեկ վայրից մյուսը՝ առանց պահանջելու, որ մշակողը հասկանա ֆայլային համակարգի գործողությունները, որոնք կատարվում են հետևում[5]։
Remove ads
Տերմինի պատմություն
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]։
1960-ականներ և 1970-ականներ
«Կիրառական ծրագրի միջերես» տերմինը (ծրագրավորման բառի փոխարեն՝ ծրագիր) առաջին անգամ արձանագրվել է 1968 թվականին AFIPS կոնֆերանսի ժամանակ ներկայացված «Տվյալների կառուցվածքներ և տեխնիկա հեռավոր համակարգչային գրաֆիկայի համար» կոչվող աշխատության մեջ[11][12]։ Այս հոդվածի հեղինակներն օգտագործել են տերմինը՝ նկարագրելու հավելվածի (այս դեպքում գրաֆիկական ծրագրի) փոխազդեցությունը համակարգչային համակարգի մնացած մասերի հետ: Հետևողական կիրառական միջերեսը (կազմված Ֆորտրան ենթածրագրային կանչերից) նախատեսված է եղել ծրագրավորողին ազատելու գրաֆիկական ցուցադրման սարքի յուրահատկություններից և ապահովելու սարքաշարի անկախությունը, եթե համակարգիչը կամ էկրանը փոխարինվեին[13]։
Տերմինը տվյալների բազա է ներմուծվել Քրիստաֆոր Դեյթի կողմից[14] 1974 թվականին «Հարաբերական և ցանցային մոտեցումներ. կիրառական ծրագրավորման միջերեսի համեմատություն» կոչվող հոդվածում[15]։ API-ն դարձել է տվյալների բազայի կառավարման համակարգերի ANSI/SPARC շրջանակի մի մասը: Այս շրջանակը վերաբերվում էր հավելվածի ծրագրավորման միջերեսին առանձին այլ միջերեսներից, ինչպիսին է հարցման միջերեսը: Տվյալների բազայի մասնագետները 1970-ականներին նկատել են, որ այս տարբեր միջերեսները կարող են համակցվել. բավականաչափ հարուստ կիրառական միջերեսը կարող է աջակցել նաև մյուս միջերեսներին[16]։
Այս դիտարկումը հանգեցրել է այն API-ների ստեղծմանը, որոնք աջակցում էին բոլոր տեսակի ծրագրավորմանը։
1990-ականներ
1990 թվականին տեխնոլոգ Մալամուդը API-ն սահմանել է որպես «ծրագրավորողին հասանելի ծառայությունների հավաքածու, որը կատարում է որոշակի առաջադրանքներ»[17]։
API-ի գաղափարը կրկին ընդլայնվել է հեռակա ընթացակարգերի կանչերի և Վեբ API-ների բախմամբ։ Համակարգչային ցանցերի տարածմամբ 1970-ականներին և 1980-ականներին, ծրագրավորողները ցանկացել են կանչել գրադարաններ, որոնք գտնվում էին ոչ միայն իրենց տեղական համակարգիչներում, այլ նաև այլ վայրերում գտնվող համակարգիչներում։ Այս հեռակա ընթացակարգերի կանչերը հատկապես լավ աջակցություն են ստացել Java լեզվի կողմից։ 1990-ականներին, ինտերնետի տարածման հետ, ստանդարտներ, ինչպիսիք են CORBA, COM և DCOM, մրցում էին՝ դառնալով API ծառայությունները ցուցադրելու ամենատարածված եղանակը[18]։
2000-ականներ
Ռոյ Ֆիլդինգի 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 տերմինը մասամբ համընկնում է հաղորդակցման պրոտոկոլի տերմինի հետ։
Remove ads
Օգտագործում
Գրադարաններ և շրջանակներ
Ծրագրային գրադարանի հետ կապված միջերեսը 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-ներ
Վեբ 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]։
Remove ads
Ձևավորում
API-ի նախագծումը էական ազդեցություն ունի դրա օգտագործման վրա[39]։ Նախևառաջ, ծրագրավորման ինտերֆեյսների ձևավորումը ներկայացնում է ծրագրային ապահովման ճարտարապետության կարևոր մասը, ծրագրային ապահովման բարդ մասի կազմակերպումը[40]։ Տեղեկատվության թաքցման սկզբունքը նկարագրում է ծրագրավորման միջերեսների դերը որպես մոդուլային ծրագրավորման հնարավորություն՝ թաքցնելով մոդուլների իրականացման մանրամասները, որպեսզի մոդուլների օգտագործողները չհասկանան մոդուլների ներսում առկա բարդությունները[41]։ Բացի նախորդ հիմքում ընկած սկզբունքից, API-ի օգտագործելիությունը չափելու այլ չափումներ կարող են ներառել այնպիսի հատկություններ, ինչպիսիք են ֆունկցիոնալ արդյունավետությունը, ընդհանուր ճիշտությունը և նորեկների համար սովորելիությունը[42]։ Ֆաբրիկային մեթոդի օրինաչափությունը նույնպես բնորոշ է API-ների նախագծման մեջ՝ դրանց բազմակի օգտագործման բնույթի պատճառով[43]։ Այսպիսով, API-ի նախագծումը փորձում է տրամադրել միայն այն գործիքները, որոնք օգտատերը ակնկալում է[39]։
Համաժամանակյա ընդդեմ անհամաժամանակյա
Դիմումների ծրագրավորման ինտերֆեյսը (API) կարող է լինել համաժամանակյա կամ անհամաժամանակյա։ Համաժամանակյա API կանչը դիզայնի այն օրինաչափությունն է, որտեղ կանչի տեղը արգելափակվում է, մինչ սպասում է կանչված կոդի ավարտին[44]։ Այն դեպքում, երբ անհամաժամանակյա API կանչ կա, կանչի տեղը չի արգելափակվում, մինչ սպասում է կանչված կոդի ավարտին, և փոխարենը կանչողը տեղեկացվում է, երբ պատասխանը հասնում է։
Remove ads
Թողարկման ձևեր
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]։
Remove ads
Փաստաթղթեր
API փաստաթղթավորումը նկարագրում է API-ի առաջարկած ծառայությունները և դրանց օգտագործման եղանակները, նպատակ ունենալով ընդգրկել այն ամենը, ինչ անհրաժեշտ է հաճախորդին գործնական նպատակներով:
Փաստաթղթավորումը շատ կարևոր է API-ով աշխատող ծրագրերի մշակման և պահպանման համար[55]։ API փաստաթղթավորումը ավանդաբար գտնվում է փաստաթղթավորման ֆայլերում, սակայն նաև կարելի է գտնել սոցիալական մեդիայում, ինչպիսիք են բլոգները, ֆորումները և հարց ու պատասխանի կայքերը[56]։
Ավանդական փաստաթղթավորման ֆայլերը հաճախ ներկայացվում են փաստաթղթավորման համակարգերի միջոցով, ինչպիսիք են Javadoc կամ Pydoc, որոնք ունեն կայուն տեսք և կառուցվածք: Այնուամենայնիվ, փաստաթղթությունում ներառվող բովանդակության տեսակները տարբեր են API-ներից[57]։
Ցուցակի հասկացողության համար, API փաստաթղթավորումը կարող է ներառել API-ում հասկացությունների և մեթոդների նկարագրություններ, ինչպես նաև «լիարժեք օգտագործման դեպքեր, կոդի նմուշներ, դիզայնի պատճառաբանություններ, կատարողականի քննարկումներ և պայմանագրեր», սակայն API ծառայությունների իրականացման մանրամասները սովորաբար բաց թողնվում են:
REST API-ի վերակացու փաստաթղթավորումը կարող է ավտոմատ կերպով ստեղծվել OpenAPI փաստաթղթից, որն է մեքենա ընթերցվող տեքստային ֆայլ, որն օգտագործում է OpenAPI Օրենքում սահմանված նախանշված ձևաչափ և սինտաքս: OpenAPI փաստաթուղթը սահմանում է հիմնական տեղեկություններ, ինչպիսիք են API-ի անունը և նկարագրությունը, ինչպես նաև նկարագրում է գործողությունները, որոնք API-ն տրամադրում է[58]։
API-ի փաստաթղթերը կարող են հարստացվել մետատվյալներով, ինչպիսիք են Java ծանոթագրությունները: Այս մետատվյալները կարող են օգտագործվել կոմպիլյատորի, գործիքների և գործարկման ժամանակի միջավայրի կողմից՝ հատուկ վարքագծերը կամ հատուկ մշակումը իրականացնելու համար[59]։
Remove ads
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]։
Remove ads
Տես նաև
Ծանոթագրություններ
Հետագա ընթերցում
Արտաքին հղումներ
Wikiwand - on
Seamless Wikipedia browsing. On steroids.
Remove ads