Vaikka API-ilmiössä korostuu palvelujen julkaiseminen organisaation ulkopuolelle, heijastuvat tekniset vaatimukset syvälle palomuurin taakse. API-palveluita kutsutaan keskitetyn integraatioratkaisun kautta. Sisäisen käytön ja julkisesti tarjottavien palveluiden rajapintatekniikoiden eriyttämiseen ei myöskään perusteita helpolla löydy. SOAP Web Service on ollut vallitsevin tekniikka palvelujen tarjoamiseen. API-ilmiön edustamien rajapintojen de facto -tekniikaksi on muodostunut REST-palvelut JSON-muotoisella viestisisällöllä. Käyttökohteen yhtäläisyydestä huolimatta tekniikoiden filosofia on täysin päin vastainen. Kaikki SOAP-palveluun liittyvät yksityiskohdat on kiinnitetty kattavissa standardeissa ja rajapinnat kuvataan hyvin yksityiskohtaisilla määrityksillä. REST-palvelujen muotoa ei ole standardoitu, eikä rajapintojen kuvaamiseen ole vakiintunutta käytäntöä.
Vuosien varrella olen useamman kerran ajautunut “SOAP vai REST” -keskusteluun. Räätälöityä sovelluskehitystä tekevät kehittäjät ovat vahvasti rummuttaneet kevyemmän REST-tekniikan puolesta. Itse olen katsonut maailmaa järjestelmäintegraatiolasien läpi ja nähnyt SOAP-tekniikassa hyviäkin puolia. SOAP-rajapintojen yksityiskohtainen kuvaus on integraatiokehitystyökaluille mahdollisuus. Graafiset kehittimet saavat tarvitsemansa tiedon rajapintakuvauksesta ja mahdollistavat sen pohjalta hyvin tehokkaan kehitystyön. Kun kaikki järjestelmät tarjoavat pilkulleen käytössä olevan kehitystyökalun kanssa yhteensopivia (huom. eri asia kuin standardin mukaisuus) SOAP-rajapintoja, on graafisilla kehittimillä työskentely hyvin tehokasta. SOAP-tekniikan suurimpia puolestapuhujia ovatkin olleet juuri integraatiotuotteiden toimittajat. Integraatiotuotteiden elinehto on laajan teknologiapaletin tukeminen, joten REST-palvelujen yleistymiseen on väistämättä jouduttu reagoimaan. Muutaman vuoden viiveellä integraatiotuotteisiin saatiin tuki REST-palvelujen tarjoamiselle ja kuluttamiselle. Nyt muutaman vuoden lisäviiveellä näitä versioita alkaa olemaan organisaatioilla jo käytössäkin. Jos organisaation integraatioalusta ei tue tehokasta REST/JSON-palvelujen käyttöä, on sen parasta ennen -päiväys auttamatta ohitettu.
Rajapintojen dokumentointia ei ole API-maailmassa standardoitu millään tavalla. Perinteisen EAI- tai SOA-lyhenteen nimeen vannoville järjestelmäintegraatiopuristeille tämä kuulostaa pöyristyttävälle. Rajapintoja tuotetaan paljolti kuitenkin ohjelmoijilta ohjelmoijille, mikä tuntuu pitävän dokumentaation kiinni hyvinkin olennaisissa asioissa. Itse koin API-valaistukseni kun vapaa-ajan puuhastelussa rakentelin dynaamista kuvagalleriaa Flickr-kuvapalvelun API:n päälle. Vuoden 2008 paikkeilla ei todellakaan ollut vakiintuneita käytäntöjä JSON-rajapintojen kuvaamiseen. Työelämässä ei kuitenkaan koskaan ollut tullut vastaan rajapintadokumentaatiota, josta olisin yhtä nopeasti päässyt kiinni rajapinnan käyttöön. SOAP:n WSDL on helppo koneen lukea, mutta liian usein törmää siitä generoituun täysin hyödyttömään “dokumentaatioon”.
API:ien kuvaaminenkin on kehittynyt ammatillisempaan suuntaan. JSON Schema -projekti tarjoaa kompaktin formaatin json-rakenteiden formaaliin kuvaamiseen. Rajapintojen laajempaan kuvaamiseen on tarjolla loistavia työkaluja, jotka myös tarjoavat tukea pidemmälle kehitykseen mm. clientien tynkien generointiin. RAML on valinnut lähestymikseen “bottom up”, eli API:n kehitys aloitetaan rajapinnan kuvaamisesta. Swagger tukee myös “top down” lähestymitä, joka automatisoi kuvauksen tuottamisen valmiille rajapinnalle. Molemmille on paikkansa oikeissa kohdissa. Hyvistä työkaluista huolimatta fakta on se että, että API-tekniikat itsessään eivät sido mihinkään tiettyyn kuvaamistapaan. Tähän pitää integraatioarkkitehdin ottaa kantaa ja kirjoittaa teesinsä integraatiokäsikirjaan. Ei ole yhtään pienempi paha antaa kaikkien kukkien kukkia dokumetointitavoissa kuin toteutustavoissakaan.
Teknisiä yksityiskohtia ja rajapintakuvaustekniikoita merkittävämpi haaste organisaatiolle muodostuu API:ien mukanaan tuomasta hallinnointivastuusta. API Management -tuotteita löytyy kattavasti markkinoilta. Ne tarjoavat valmiina API:ien julkaisemiseen liittyviä työkaluja. Tuotteiden ominaisuus listoilta löytyy esimerkiksi API-avainten myöntäminen ja hallinnointi, rajapintadokumentaation julkaisu, palveluesto- ja ruuhkautumistilanteisiin varautuminen sekä tunnistamisen ja salaamisen ratkaisujen kattava tuki. Aivan oma osa-aluuensa on tuki API:ien varassa pyöritettäville liiketoimintamalleille, jossa tuotteet osaavat ottaa huomioon viestiliikenteen ohella käsitteen raha. Muutaman yksittäisen rajapinnan saa varmastin järkevästi julkaistua myös perinteisempien web reverse proxy -ratkaisujen avulla, mutta vähänkään laajemmassa käytössä on organisaation järkevä tehdä teknologia-PoC ja valita omaan käyttöön soveltuvin API Management -ratkaisu. Vaihtoehtoja kyllä löytyy, eikä se optimi-ratkaisu välttämättä löydy sen suuren toimittajan paletista, joka muun middleware-ratkaisun on toimittanut. Paras ratkaisu voi käyttötarpeesta riippuen hyvin leijua myös pilvessä.
API:en julkaisussa on hyvä huomioida mobiilisovellusten vaikutus. Vaikka mobiilisovellus olisi oman organisaation käyttöön sovelluskaupan kautta julkaistu työkalu, on se arkkitehtuurimielessä hyvin eri tyyppinen kuin saman toiminnon intranetin sivulla tarjoava sovellus. Mobiilisovellus on lähtökohtaisesti yhteydessä kaupallisessa verkkoyhteydessä ja palvelupyynnöt saapuvat samaan tapaan julkisesta verkosta kuin minkä tahansa käyttäjän pyynnöt. Mobiilisovellukset harvoin tallentavat merkittävästi tietoa tai tekevät itsenäisesti pidempiä toimintoja. Mobiilisovellukset ovat hyvin tiukasti sidoksissa API:en tarjoamaan toiminnallisuuteen ja tietyt sovellukset ovatkin hyvin selkeitä API:en visuaalisia ilmentymiä. Mobiilisovellusten tarjoaminen lisää siis nopeasti myös tarvetta API:en hallintaratkaisun kehittämiseen.
API Management -tuotteiden kautta korostuu API:en julkaisun tekniset haasteet, joita ne ratkaisevat. Valitettavasti API:en hallinnointiin liittyy myös ihmisten toimintatapoja, jotka pitää myös huomioida. Kun uusi valituille kumppaneille julkaistava API valmistuu, kuka hoitaa julkaisun ja API-avainten komminikoinnin tekinisille yhteyshenkilöille? Voiko tunnusten luomisen avata kaikille avoimeksi itsepalvelutoiminnoksi vai pitääkö tunnuspyyntöjen käsittely vastuuttaa henkilöstölle? Miten käsitellään julkaistun rajapinnan kehitytoiveet tai reagoidaan havaittuun väärinkäytösyritykseen? Kaikkea ei varmasti ole mahdollista tai järkevääkään etukäteen määritellä, mutta välttämätöntä on huomioida API-maailmaan siirtymisen mukanaan tuomat vastuut, joita ei teknisesti ole mahdollista ratkaista.
Teknisesti API on vain uudelleen syntynyt palvelu, eikä sen käyttö järjestelmäintegraatiokontekstissa ole ongelma vaan ennemminkin päinvastoin. Koosteisien palvelujen rajapintoja tai vaikka ajettaviksi mallinnettuja liiketoimintaprosesseja voi alkaa julkaisemaan API:ien kanssa yhtenevällä tekniikalla ja palvelujen kuluttajat todennäköisesti ovat vain tyytyväisiä. Merkittävämpi vaikutus integraatioarkkitehtuuriin on API:en julkaisun mukanaan tuoma hallinnointivastuu, joka vaatii uuden teknisen kyvykkyyden ja toimintamallien luomista.
