Aplikacijų programavimo sąsaja
Aplikacijų programavimo sąsaja (angl. Application Programming Interface, API) – tai sąsaja, kurią suteikia kompiuterinė sistema, biblioteka ar programa tam, kad programuotojas per kitą programą galėtų pasiekti jos funkcionalumą ar apsikeistų su ja duomenimis.
Aprašymas[redaguoti | redaguoti vikitekstą]
Viena iš pagrindinių API funkcijų – tai viešai pasiekiamų funkcijų, klasių, metodų apibrėžimas, kuriomis programuotojas gali pasiekti tam tikrą funkcionalumą, pavyzdžiui, nupiešti langą ekraną, naudojant tam skirtą biblioteką. Kaip ir dauguma sąsajų, API yra abstrakcija. Tiek žemo lygio, tiek aukšto lygio sąsają API apibrėžia per aukšto lygio sąsają.
Pavyzdžiui, beveik visos operacinės sistemos turi savo API, todėl programuotojas gali parašyti jai programinę įrangą. Kompiuterinė programa gali, o dažniausiai ir turi naudoti jos API (ar kitą API, aprėpiančią šią) tam, kad galėtų valdyti atmintį, failinę sistemą, kitas operacinės sistemos dalis. Dauguma programų ir sistemų tipų, kaip grafinės sistemos, web servisai ir netgi kai kurie žaidimai, realizuoja savo aplikacijų programavimo sąsają. Vieningos API naudojimas dažnai reiškia panašią vartotojo sąsają, taigi naudotojui lengviau prisitaikyti prie naujų programų.
Egzistuoja ir kita medalio pusė. Skirtingos operacinių sistemų API apsunkina programų pernešamumą tarp skirtingų OS. Šiai problemai išspręsti naudojami įvairūs metodai: nuo „tarpinių“ API sukūrimo (pvz.: GTK, QT), programavimo kalbų API standartizavimo (standartinė C biblioteka, Java), iki įvairių interpretatorių (PHP, python).
Paprastai programuotojas susiduria bent su keliomis skirtingomis API, atliekančiomis tą pačią funkciją. Jas galima atvaizduoti kaip medį, kur žemiausias lygis yra pats sudėtingiausias, bet funkcionaliausias ir atvirkščiai, aukščiausias yra parašytas žemesnio pagrindu, supaprastintas ir lengviau išmokstamas, tačiau jis praranda ir dalį funkcionalumo, kurį galėtum pasiekti žemesniu lygiu.
API modeliai[redaguoti | redaguoti vikitekstą]
Egzistuoja įvairūs API dizaino modeliai. Sąsajos, kurios skirtos greitam vykdymui, paprastai sudarytos iš funkcijų, procedūrų, kintamųjų ir duomenų struktūrų. Egzistuoja ir kiti modeliai, pavyzdžiui, interpretatorius, kuris įvertina reiškinių reikšmes JavaScript kalboje ar abstrakcijos lygyje, kas palengvina programuotojo darbą, leidžia jam nesigilinti į žemesnio lygio abstrakcijas. Taip pačios API tobulinimas tampa paprastesnis, nesulaužant suderinamumo su kodu, kuris buvo parašytas remiantis šia API.
API publikavimo politika[redaguoti | redaguoti vikitekstą]
Egzistuoja dvi pagrindinės API publikavimo politikos:
- Kai kurios kompanijos karštai gina savo API nuo viešo publikavimo. Pavyzdžiui, oficialų Sony PlayStation 2 API gali pamatyti tik licencijuoti programuotojai. Tai padaryta tam, kad Sony galėtų kontroliuoti žaidimų kūrėjus ir jų skaičių bei pasipelnyti iš licencijų pardavimo.
- Kitos kompanijos platina savo API laisvai. Pavyzdžiui, didžioji dalis Microsoft, Sun Microsystems sistemų API yra viešai prieinama.
- Jei API platinama laisvai, autoriai gali leisti arba drausti alternatyvių tos pačios API išpildymų kūrimą. Jei tai leidžiama, autoriai gali kelti įvairias papildomas sąlygas.
API, kurios nereikalauja autorių honoraro, vadinamos „atvirosiomis“. API, kurią suteikia atviro kodo programos (pavyzdžiui, išleistos pagal GNU GPL licenciją), yra atviros pagal apibrėžimą, nes kiekvienas gali pažiūrėt į programos kodą ir perprasti ją.
Alternatyvios API[redaguoti | redaguoti vikitekstą]
Nors dažniausiai egzistuoja tik viena konkrečios API realizacija, visada yra galimybė sukurti jai alternatyvią. Pavyzdžiui, GNU Classpath kuria Sun Microsystems alternatyvią atviro kodo java API. Pati Sun siūlo tos pačios java API išpildymą įvairioms operacinėms sistemoms (Windows, Linux). Didelė dalis Win32 API gali būti pasiekta UNIX sistemose, naudojant Wine programą.
Tačiau net šalyse, kur programinės įrangos patentai negalioja, API gali būti apsaugotos paprastomis autorių teisėmis. Todėl prieš kuriant alternatyvą, aiškinamasi, kokias sąlygas kelia autoriai ir ar apskritai jie su tuo sutinka. Pavyzdžiui, Sun Microsystems java alternatyva turi būti sukurta be nukrypimų (negalima nei dėti papildomų funkcijų, nei šalinti atrodančių nereikalingomis). Užbaigta alternatyvi API turi būti patikrinta pačios Sun parengtais testais (TCK), ir tik tada ją galima oficialiai platinti kaip užbaigtą sistemą.
Keletas API pavyzdžių[redaguoti | redaguoti vikitekstą]
Operacinių sistemų API[redaguoti | redaguoti vikitekstą]
Grafinių sąsajų API[redaguoti | redaguoti vikitekstą]
Nuorodos[redaguoti | redaguoti vikitekstą]
- How to design a good API and why it matters (skaidrės anglų kalba)-PDF Archyvuota kopija 2011-09-03 iš Wayback Machine projekto.