Tänapäeva digitaalses maailmas kuuleme pidevalt termineid, mis tunduvad keerulised, kuid on tegelikult meie igapäevase elu lahutamatud osad. Oled sa kunagi mõelnud, kuidas suudab Uberi rakendus näidata auto asukohta Google’i kaardil ilma, et Uber ise oleks kaardirakendust ehitanud? Või kuidas reisibüroo veebileht suudab sekunditega kuvada lennupiletite hinnad viielt erinevalt lennufirmalt ühes vaates? Vastus peitub kolmes tähes: API. See on nähtamatu mootor ja ühenduslüli, mis paneb erinevad tarkvarad omavahel suhtlema, võimaldades meil nautida sujuvat ja integreeritud kasutajakogemust. Ilma nendeta oleks internet palju fragmentaarsem ja kohmakam paik.
Mis peitub lühendi API taga?
Lühend API tuleneb ingliskeelsest terminist Application Programming Interface, mis eesti keeles tähendab rakendusliidest. Et seda mõistet “puust ja punaseks” teha, tuleks vaadata iga sõna eraldi:
- Application (Rakendus): See viitab mis tahes tarkvarale, olgu selleks nutitelefoni äpp, veebileht või keerukas serveriprogramm.
- Programming (Programmeerimine): See viitab koodile ja loogikale, mida arendajad kirjutavad, et tarkvara töötaks.
- Interface (Liides): See on kohtumispaik või sild, kus kaks osapoolt suhtlevad. Nii nagu sularahaautomaadi ekraan on liides sinu ja panga andmebaasi vahel, on API liides kahe tarkvara vahel.
Lihtsustatult öeldes on API reeglite ja protokollide kogum, mis määrab, kuidas erinevad tarkvarakomponendid peaksid üksteisega suhtlema. See on justkui leping või kokkulepe: kui sina küsid andmeid kindlal viisil, siis mina vastan sulle kindlal viisil.
Kuidas API töötab? Legendaarne restorani analoogia
Kõige parem viis API tööpõhimõtte mõistmiseks on kasutada klassikalist restorani võrdlust. Kujuta ette, et oled restoranis klient. Sa istud lauas ja soovid tellida süüa. Köök on koht, kus toitu valmistatakse – see on süsteemi “tagaosa”, kus asuvad andmebaasid ja serverid.
Siin tekib aga probleem: sina (klient/kasutaja) ei saa minna otse kööki ja hakata kokkadega rääkima või ise külmkapist asju otsima. See tekitaks kaose. Sul on vaja vahendajat, kes võtab sinu soovi, viib selle kööki, edastab selle kokkadele arusaadavas keeles ja toob lõpuks tellitud toidu sinuni.
Selles näites on kelner sinu API. Protsess näeb välja järgmine:
- Päring (Request): Sa vaatad menüüd (dokumentatsioon) ja ütled kelnerile, mida soovid (teed päringu).
- Töötlus: Kelner viib tellimuse kööki. Ta ei tee ise süüa, vaid edastab info süsteemile (köögile), mis omab ressursse.
- Vastus (Response): Köök valmistab toidu. Kelner toob selle sinuni. Kui toitu pole, tuleb kelner tagasi ja ütleb, et see on otsas (veateade).
Täpselt nii toimivad ka digitaalsed API-d. Sinu telefon (klient) saadab sõnumi serverile (köök) läbi API (kelner), küsides näiteks “mis on homne ilm Tallinnas?”. API võtab selle info, edastab ilmajaama andmebaasile ja toob vastuse sinu ekraanile.
Tehniline vaade: mis toimub kapoti all?
Kui liigume analoogiatest reaalsesse tehnoloogiasse, siis API suhtlus toimub tavaliselt üle interneti, kasutades HTTP protokolli. Arendajad kasutavad API-dega suhtlemiseks kindlat struktuuri.
Päringu komponendid
Kui arendaja soovib API kaudu andmeid saada, paneb ta kokku päringu, mis koosneb tavaliselt neljast osast:
- URL (Aadress): See on unikaalne aadress ehk “endpoint”, kuhu päring saadetakse.
- Meetod: See ütleb API-le, mida teha. Levinumad on GET (andmete küsimine), POST (uute andmete saatmine), PUT (andmete muutmine) ja DELETE (andmete kustutamine).
- Päised (Headers): Siin on meta-info, näiteks autentimisvõtmed või info selle kohta, mis formaadis vastust oodatakse (tavaliselt JSON).
- Keha (Body): Andmed, mida saadetakse serverisse (vajalik peamiselt POST ja PUT meetodite puhul).
Kui server saab päringu kätte, töötleb ta seda ja saadab tagasi vastuse. Vastus sisaldab tavaliselt olekukoodi. Oled kindlasti näinud viga “404 Not Found” – see on API vastus, mis ütleb, et otsitud ressurssi ei leitud. Edukas päring saab koodi “200 OK”.
Erinevad API tüübid ja arhitektuurid
Mitte kõik API-d ei ole loodud võrdselt. Sõltuvalt ligipääsetavusest ja eesmärgist jagunevad need nelja peamisesse kategooriasse:
1. Avalikud API-d (Open APIs)
Need on kättesaadavad kõigile arendajatele ja avalikkusele. Sageli on need mõeldud innovatsiooni soodustamiseks. Näiteks Google Maps API või Twitteri API, mida saavad kasutada kõik, kes soovivad ehitada oma rakendusi nende platvormide andmete põhjal (tihti küll piiratud mahus või tasu eest).
2. Partner API-d
Need ei ole avalikud, vaid mõeldud kindlatele äripartneritele. Ligipääsuks on vaja spetsiaalseid õigusi ja lepinguid. Näiteks võib e-pood kasutada kullerfirma API-t, et saata pakiautomaadi infot otse oma süsteemist.
3. Sisemised API-d (Internal/Private APIs)
Neid kasutatakse ettevõtte siseselt erinevate süsteemide ühendamiseks. Tavakasutaja neid ei näe. Näiteks panga mobiiliäpp suhtleb panga tuumiksüsteemiga just sellise sisemise liidese kaudu. See aitab ettevõtetel olla efektiivsem ja vähendada arenduskulusid.
4. Liit-API-d (Composite APIs)
Need ühendavad mitu erinevat andmeallikat või API-t üheks tervikuks. See on kasulik keerukate toimingute puhul, kus ühe päringuga on vaja saada infot mitmest kohast korraga, et süsteem ei peaks tegema kümneid eraldiseisvaid päringuid.
Miks on API-d kaasaegses majanduses kriitilise tähtsusega?
Me elame ajastul, mida nimetatakse sageli API majanduseks. Ettevõtted ei ehita enam kõike ise nullist üles. Selle asemel kasutatakse “Lego klotside” põhimõtet, kus erinevad teenused ühendatakse API-de abil.
Mõtle näiteks Uberile. Nad ei loonud oma kaardirakendust (kasutavad Google Maps API-t), nad ei ehitanud oma maksesüsteemi (kasutavad Braintree või Stripe API-t) ja nad ei saada ise SMS-teavitusi (kasutavad Twilio API-t). Uberi geniaalsus seisneb selles, et nad sidusid need olemasolevad teenused API-de kaudu kokku, luues täiesti uue väärtuse.
See lähenemine võimaldab ettevõtetel:
- Kiirendada innovatsiooni: Uue toote turule toomine võtab aasta asemel kuid.
- Säästa raha: Pole mõtet kulutada miljoneid oma makselahenduse arendamisele, kui Stripe teeb seda paremini.
- Laiendada haaret: Kui ettevõte teeb oma API avalikuks, võivad teised arendajad ehitada selle peale uusi teenuseid, tuues algsele ettevõttele tulu.
Turvalisus: Kuidas kaitstakse andmeid?
Kuna API-d on väravad andmebaasidesse, on nende turvalisus ülioluline. Ei saa lubada, et igaüks pääseks ligi suvalistele andmetele. Siin tulevad mängu API võtmed (API Keys) ja autentimistokenid.
Kui arendaja tahab kasutada näiteks ilmateenuse API-t, peab ta end registreerima ja saab unikaalse pika koodijada – võtme. Iga kord, kui tema rakendus saadab päringu (näiteks “milline on ilm Tartus?”), peab ta selle võtme kaasa panema. See võimaldab serveril tuvastada, kes küsib, ja kontrollida, kas tal on selleks õigus. Samuti aitab see piirata päringute arvu, et keegi ei koormaks süsteemi pahatahtlikult üle.
Korduma kippuvad küsimused (FAQ)
Kas API kasutamine on tavainimesele tasuline?
Tavakasutajale on API-d nähtamatud ja tasuta, kuna need on peidetud rakenduste sisse, mida me igapäevaselt kasutame. Arendajatele, kes neid API-sid oma tarkvarasse integreerivad, on mudelid erinevad: on tasuta API-sid, tasulisi (kuutasu või tasu per päring) ja “freemium” mudeleid, kus väike maht on tasuta.
Kas ma pean oskama programmeerida, et API-t kasutada?
Et API-t otse kasutada ja sellega uusi rakendusi luua, on üldiselt vaja programmeerimisoskust. Siiski on olemas tööriistu (nagu Zapier või IFTTT), mis võimaldavad ühendada erinevaid API-sid ilma koodi kirjutamata, automatiseerides lihtsaid ülesandeid (nt “kui saan emaili, salvesta manus Dropboxi”).
Mis vahe on REST ja SOAP API-l?
SOAP (Simple Object Access Protocol) on vanem, rangem ja keerulisem standard, mida kasutatakse siiani suurtes ettevõtetes ja panganduses kõrge turvalisuse tõttu. REST (Representational State Transfer) on uuem, paindlikum ja kergem arhitektuuristiil, mis on saanud veebi standardiks. Enamik tänapäevaseid avalikke API-sid on REST-põhised.
Mis juhtub, kui API lakkab töötamast?
Kui API, millest sinu rakendus sõltub, läheb katki või server on maas, lakkab ka vastav funktsioon sinu rakenduses töötamast. Näiteks kui ilmateenuse API on maas, näitab sinu nutikella sihverplaat ilmainfo asemel tühjust või veateadet, kuigi kell ise töötab.
API roll digitaalses ökosüsteemis
Vaadates tulevikku, muutub API-de roll üha kesksemaks. Asjade internet (IoT) ehk nutikad külmkapid, targad termostaadid ja isesõitvad autod suhtlevad omavahel just nimelt API-de kaudu. See tehnoloogia on muutnud viisi, kuidas ettevõtted teevad koostööd ja kuidas tarkvara ehitatakse.
API ei ole lihtsalt tehniline termin arendajatele; see on digitaalse ühiskonna vereringe. Mõistes, kuidas see “nähtamatu kelner” andmeid liigutab, mõistame paremini ka maailma, milles me igapäevaselt toimetame. Järgmine kord, kui broneerid lennupileti või logid Facebookiga uude portaali sisse, tead täpselt, et selle sujuva kogemuse taga töötab väsimatult üks hästi disainitud rakendusliides.
