Avoin API voi olla avoin kaikille eli julkinen API tai tarkoittaa vain mitä tahansa ulkopuolisille esim. kumppaneille avointa APIa. Jotkut saattavat sekoittaa sen OpenAPI-standardiin (huomaa puuttuva välilyönti), joka tunnettiin aiemmin nimellä Swagger. On turvallista sanoa, että APIn avoimuus ei ole niin yksinkertainen asia kuin avoimen datan tai avoimen lähdekoodin tapauksessa. On kuitenkin olemassa tekijöitä, jotka edistävät APIn laajentuvaa käyttöä.
On erittäin vaativaa laatia yksiselitteinen määritelmä avoimelle APIlle, josta myös avoin rajapinta -nimitystä käytetään suomeksi. Keskustelu muuttuu nopeasti arvokeskusteluksi ja tavoitteiden asettamiseksi sanakirjamääritelmän sijaan. Englanninkielisellä termillä Open API on ollut hyvin erilainen tausta ja tarkoitus kuin esimerkiksi avoimella datalla tai avoimen lähdekoodin käsitteillä.
Saat sitä mitä tilaat. Haluatko APIasi käytettäväksi laajimmalle joukolle kuluttajia, jotka tuottavat vaikuttavan tuloksen? Sitten sinun on kiinnitettävä huomiota siihen, miten API tarjotaan ja hankitaan. Varsinkin jos tilaat kehitystyötä, tuotetta tai tekniikkaa, joka sisältää rajapintoja. Oikeudellisilla seikoilla, kuten käyttöehdoilla, on myös keskeinen rooli APIn avoimuudessa.
Julkisen ja yksityisen sektorin tavoitteet voivat joskus vaikuttaa ristiriitaisilta, kun on kyse rajapintojen avoimuudesta. Julkinen sektori ja kansalaisjärjestöt ovat viime aikoina ajaneet innokkaasti avoimen datan palveluita. Tämä johtuu avoimuusvaatimuksista, mutta myös toimittajalukkojen välttämisestä. Seuraava askel on kehittää sovelluksia avoimena lähdekoodina ja siten tarjota avointa dataa rajapintojen kautta. Vaikuttaa loogiselta, että jos avointa dataa ja avointa lähdekoodia voidaan käyttää laajasti ja enimmäkseen ilmaiseksi valitusta avoimesta lisenssistä riippuen, niin miksi ei "avoimia rajapintoja". Mutta tässä piileekin se pieni ero. Eli vaikka avoin data, avoin lähdekoodi ja avoin API sisältävät kaikki sanan avoin, niiden historiallinen kehitys on ollut erilainen.
Usein tavoite APIn tarjoamisella on lisätä liiketoiminnallisia tai yhteiskunnallisia hyötyjä. Tämä edellyttää yleensä sitä, että API otetaan käyttöön mahdollisimman laajalti. Vaikka kaikki alla olevat syyt ovat järkeviä ulkoisille rajapinnoille, joita usein kutsutaan julkinen- tai kumppani-API -nimillä, ovat monet niistä olennaisia myös sisäisessä käytössä oleville rajapinnoille.
Laajalti käytössä oleva API tarjoaa:
On olemassa useita tapoja varmistaa, API otetaan laajalti käyttöön. Yksi tapa on standardoida API, mikä voi olla hidas prosessi. Toinen vaihtoehto on luoda niin sanottu de facto -standardi. Tämä tarkoittaa tapoja varmistaa, että APIn on omaksunut suuri ja kasvava joukko hyödyntäjiä.
Vain toteuttamalla helppokäyttöinen, hyvin dokumentoitu, virheetön ja riittävän hyvin toimiva API, sen käytön voidaan odottaa lisääntyvän. Lisäksi saadaksesi APIsi laajalti käytetyksi, se tarvitsee samoja asioita kuin avoimen lähdekoodin ohjelmistot:
Mitä avoimempi API on, sitä paremmin se täyttää myös nämä vaatimukset:
Jos kaikilla kiinnostuneilla kolmansilla osapuolilla on pääsy APIin, käytetään usein käsitettä julkinen API. Jos vain valitut organisaation ulkopuoliset osapuolet saavat käyttää APIa, on kyseessä kumppani API. Näiden lisäksi organisaation eri osat voivat tarjota rajapintoja itselleen ja toisilleen, jolloin niitä kutsutaan sisäisiksi rajapinnoiksi. Monissa lähteissä avoimet APIt määritellään julkisiksi. Jotkin lähteet sisällyttävät käsitteeseen myös kumppanien APIt. (Moilanen, Niinioja, Seppänen, Honkanen, API-talous 101, 2018)
APIn avoimuutta voidaan parantaa lisensoimalla avoimesti tietomallit, dokumentaatio ja ohjeet. APIn olisi mahdollisuuksien mukaan käytettävä myös vakiomuotoisia tietomalleja.
Avointen lisenssien ja standardien käyttö on erityisen tärkeää, jos API vaatii myös osapuolia kopioimaan API omiin tietojärjestelmiinsä ja -teknologioihinsa. Tämä liittyy tyypillisesti avoimen lähdekoodin ohjelmistoihin, jotka sisältävät APIn. Yksinkertaisesti APIn rajapintakuvauksen tai tietomallin kopiointi ei riitä varmistamaan, että API toimii samalla tavalla tai että tulevat versiot ovat yhteensopivia. Yhteinen tai integroitu tekninen toteutus sekä avoin kehittäjätiimi voivat olla tärkeämpiä kuin avoin lisensointi yksinään.
Avoin lisensointi voi edistää kehittäjäryhmän muodostumista ja kiinnostusta. Jos koko järjestelmän lähdekoodi on lisensoitu avoimella lisenssillä, resurssit, jotka liittyvät API voidaan sisällyttää tähän lisenssiin. Jos ohjelmisto tai muu tekniikka, joka toteuttaa APIn on kopioitu, tietojen käyttöehdot voidaan erottaa kokonaan APIsta. Tämä tarkoittaa, että kunkin hyödyntäjän käyttämä API toimii omassa verkossaan, omilla laitteillaan tai pilvessä omassa hallinnassaan. API on myös yhteydessä ainoastaan omien resurssiensa kanssa (tiedot, rakennukset, algoritmit jne.).
Ei läheskään aina, mutta mahdollisuuksia siihen olisi useammin kuin ehkä ajatellaan. Esimerkiksi yritysten verohallinnolle rajapintojen kautta ilmoittamat verotustiedot eivät sellaisenaan ole avointa dataa, vaikka rajapinta olisikin avoimesti kaikkien halukkaiden yritysten käytettävissä. Osa datasta voidaan tosin julkaista esimerkiksi julkisuuslain tai muun verotustietoihin liittyvän lainsäädännön perusteella avoimena datana.
Jos API hyödyntäjät ovat itse asiassa SaaS-käyttäjiä ja maksavat ohjelmistotilauksesta, tiedoista, joita he käyttävät API sisältää "heidän tietonsa" ja on "ilmainen" siinä mielessä, että he eivät nimenomaisesti maksa APIsta tai APIn tarjoamista tiedoista. Mutta sekin olisi mahdollista, riippuen ehdoista. Ja heille voi olla rajoituksia sille, kuinka paljon tietoja ja kuinka usein he voivat pyytää maksamatta ylimääräistä.
Avoimen datan ja avoimen lähdekoodin ajatellaan usein olevan maksuttomia. Jotkut määritelmät sallivat myös kohtuullisen maksun keräämisen tietojen tai lähdekoodin avaamisesta. On kuitenkin tärkeää erottaa tiedot ja lähdekoodi itse APIsta.
Ilmainen tai edullinen API on varmasti suositumpi ja laajemmin käytetty kuin maksullinen API. Aina on myös freemium-vaihtoehtoja, joissa käyttäjä saa APIn tietyksi ajaksi ilmaiseksi käyttöön tai tietyn määrän ilmaisia API-kutsuja.
Avoimen datan, avoimen lähdekoodin ja avoimen APIn välisten erojen tärkein ero on se, että avoin tai "suljettu" eli julkinen, kumppani tai sisäinen API voidaan rakentaa avoimella lähdekoodilla (tai ei). Se voi tarjota tietoja avoimella lisenssillä - tai ei. APIn rajapintakuvaus- ja dokumentaatio voidaan lisensoida avoimella lisenssillä - tai ei. Alan standardeista, lainsäädännöstä, käyttötapauksista ja yhteisön odotuksista riippuen paras valinta on olla mahdollisimman avoin, mutta muistaa realiteetit. Jonkun on lopulta pystyttävä maksamaan lasku.