API:en hallinta – Mitä ja miksi?

Lokakuussa 2016 Google osti API:en hallintaa (API Management) palveluna tuottavan yrityksen apigee:n 625 miljoonalla dollarilla. Mitä tämä mystinen API:en hallinta on ja miksi siitä pitäisi olla kiinnostunut?

API:en hallinta -innostusta ymmärtääkseen pitää ensin ymmärtää mitä API:t ovat ja miksi ne ovat ohjelmistokehityksessä keskeisessä roolissa. Aloitetaan siitä.

Application Programming Interface (API)

API:en avulla sovellus tarjoaa palvelujaan muiden sovellusten tai sovellusten osien käyttöön yksinkertaisella tavalla. Palvelu voi olla esimerkiksi:

• Uuden käyttäjän luonti
• Käyttäjän X osoitteen kysyminen
• Rahan siirtäminen tililtä A tilille B
• Uuden tilauksen luonti
• Tilauksen X tilan kysyminen
• Lennon X vapaiden istumapaikkojen määrän kysyminen

 

 

Sovelluksia ei tarvitse kehittää samoilla työkaluilla. Sovellus 1 voi olla .Net -sovellus Windows-palvelimella ja sovellus 2 Node.js -sovellus Linux-palvelimella. Riittää kun tiedetään mistä käytettävä API löytyy (esim URL-osoite), mitä parametreja sille annetaan ja missä muodossa API palauttaa vastauksen.

API:t ohjelmiston sisäisessä kommunikoinnissa

Isoja ohjelmistoja rakennetaan koostamalla ne pienemmistä itsenäisistä osista (moduli, komponentti, palvelu tms). Osat kommunikoivat usein erilaisten API:en avulla.

Hyödyt ovat ilmeisiä, esimerkiksi:

• Eri moduleita voi kehittää omat tiiminsä
• Eri moduleita voidaan kehittää eri kehitysvälineillä- ja kielillä
• Testaus tehokkaampaa (testataan vain muuttuneet modulit ja rajapinnat)
• Ratkaisun laajentaminen yksinkertaisempaa
• Tarvittaessa yksittäinen moduli voidaan helposti kokonaan uudelleen kirjoittaa (valittu toteutustapa ei olekaan enää riittävän suorituskykyinen palvelun suosion kasvettua)

Käyttöliittymäkerroksen eriyttäminen API:en avulla

Ohjelmisto voidaan rakentaa siten että käyttöliittymäkerros kommunikoi ainoastaan rajapintojen avulla muiden ratkaisun osien kanssa.

 

Tämä on luontevaa mikäli tarkoitus on tarjota 3. osapuolille mahdollisuus rakentaa ratkaisuja ja omia käyttöliittymiään ohjelmiston päälle. Samat API:t kun pitää tehdä joka tapauksessa.

 

API:t – Organisaation hyödyntämätön omaisuus

Nyt kun ymmärretään mitä API:t ovat, voidaan miettiä mikä niiden merkitys on organisaatiolle.

API:t organisaation sovelluskehityksessä

Pientäkin uutta sovellusta tehdessä kehittäjä käyttää usein hyväkseen organisaation valmiita palveluja. Tai ainakin pitäisi käyttää. Sovellus tarvitsee esimerkiksi:

• Asiakkaan X yhteystiedot
• Listan organisaation myymistä tuotteista luokiteltuna tarjoamittain
• Käyttäjän sisäisen osoitetiedon
• Tiedon siitä milloin tuotteen x toimitus osoitteeseen Y on perillä jos tilaus tehdään nyt

Esimerkkiorganisaatiossamme kaikki tämä tieto olisi saatavilla olemassa olevista järjestelmistä rajapintojen kautta. Jos vain tietäisi miten rajapintoihin pääsee käsiksi:

• Keltä kysyä mitä API:a voisi käyttää
• Missä on API:n dokumentaatio
• Miten tunnistautuminen hoidetaan?
• Tarvitaanko tietoliikenneavauksia
• jne.

Pahimmillaan eri projekteissa toteutetaan samoja asioita, vaikka voitaisiin käyttää yhtä yleiskäyttöistä palvelua.

Ongelmaa havainnollistaa kuva organisaation sovelluksista. Laatikon väri kertoo mikä liiketoiminta omistaa sovelluksen. Jokainen nuoli edustaa useaa API:a.  Oikeasti sovelluksia voi olla monikymmenkertainen määrä. Käsissä on nopeasti satoja rajapintoja, joidenka olemassaoloa ja omistajaa voi olla hankalaa tietää.

 

Ei ihme että olemassa olevia rajapintoja ei aina hyödynnetä.

Organisaation API:en hallinta

Tähän kaaokseen iskevät API:en hallinta -tuotteet. Niiden avulla organisaation API:t julkaistaan yhteen paikkaan kehittäjien käytettäväksi.

 

Kun kehittäjä tarvitsee sovellukseen asiakkaan yhteyshenkilön nimen, hän menee API Management -työkalun tarjoaman kehittäjä-portaalin API-hakemistoon ja etsii sieltä getCustomerContactName API:n. Samasta paikasta hän löytää kyseisen rajapinnan dokumentaation.

Kehittäjän ei tarvitse edes tietää mistä taustajärjestelmästä tieto oikeasti haetaan.

API:en jakaminen organisaation ulkopuolelle

Kun API:t on otettu haltuun, voidaan miettiä miten niistä saataisiin kaikki hyöty irti. Työkalut sisältävät API:en käyttöoikeuksien hallinnan, jolloin voimme tarjota eri API-kokonaisuuksia eri kohderyhmille. Esimerkiksi:

• omille kehittäjille kaikki
• alihankintana hankituille kehittäjille lähes kaikki
• asiakkaille jotain
• kumppaneille jotain
• koko maailmalle Internet:iin julkaistuna jotain

Tarjotut rajapinnat voivat olla arvokkaita 3. osapuolille, jotka hyödyntävät niitä omissa sovelluksissaan. Silloin niiden käytöllä voidaan tehdä rahaa. Salesforce:n liikevaihdosta 50% muodostuu API:en käytöstä.

API:en käytön raportointi

Kun kaikki API:en käyttö kulkee API:en hallintatyökalun kautta, saadaan niiden käytöstä kerättyä arvokasta tietoa. Esimerkiksi:

• Miten paljon kutakin API:a käytetään, paljonko niissä on liikennettä
• Miten paljon kunkin API:n kutsuista päättyy virheeseen
• Mitkä ovat eri rajapintojen vasteajat
• Mitä rajapintoja kukin kehittäjä käyttää
• Mitä rajapintoja kukin sovellus käyttää

Raporttien perusteella voidaan tehdä johtopäätöksiä:

• Minkä rajapintojen suorituskyky ei ole riittävä
• Mitkä rajapinnat ovat laajasti käytössä
• Mitkä ja keiden tekemät sovellukset käyttävät generoivat paljon liikennettä
• Sovellukset joiden API-kutsut päättyvät muita useammin virheisiin
• Kehittäjät joiden API-kutsut päättyvät muita useammin virheisiin
• Jos API x:ää muokataan, miten suuri vaikutus sillä on? Paljonko sitä käytetään ja miten moni sovellus sitä käyttää?

Kuva yhdestä apigeen:n raportista koskien valittua API:a:

Kuva: http://docs.apigee.com/analytics-services/content/using-analytics-dashboards

API:t ja sovellusten modernisointi

Monet organisaatiot painivat legacy-sovellusten kanssa. Näitä vanhoilla teknologioilla toteutettuja sovelluksia on työläs ylläpitää ja laajentaa.

Ongelmaa voi lähestyä API:en kautta. Ei tehdä muutoksia vanhaan sovellukseen vaan luodaan tarvittavat rajapinnat ja julkaistaan ne. Uusi osuus toteutetaan uusilla teknologioilla, jotka käyttävät legacy-osuuden tarjoamia rajapintoja.

Selkeästä kuvasta huolimatta temppu on helppo, vaikea tai mahdoton. Riippuu täysin miten ja millä teknologialla vanha osuus on toteutettu.

Lopuksi

API:en hallinta on mielenkiintoinen aihe. API:t pitää kuitenkin olla olemassa ennen kuin niitä voi hallita. Ja hallinta on työtä jonka joku pitää tehdä. Työkalut tukevat tätä uutta työtä hyvin. Uskon että tuska vähenee ja tuottavuus kasvaa kun API:t on saatu ojennukseen.