No jotka seuraa API -talouteen liittyvää uutisointia pelkkiä lukuja syvemmälle siihen tekemiseen liittyviin asioihin on varmasti törmännyt laita tähän jotain eteeen -first konsepteihin tai termeihin. Tämä liittyy myös siihen että kun moni kyselee että mistä pitäisi aloittaa. Noh, ensimmäinen asia on ymmärtää mistä API -taloudessa on kyse ja se ei tapahdu minkään dogmaattisen yhden tulokulman mallin avulla. Sen sijaan kannattaa tutustua verkosta löytyvään materiaaliin tai sitten ostaa API talous 101 kirja.

Ainakin seuraavat vilahtelee blogeissa, tutkimuskirjallisuudessa, tapahtumissa ja keskusteluissa:

API first
API-first takana on ajatus siitä että ensin tehdään API ja sen jälkeen APIa hyödyntäen tarvittavat käyttöliittymät - eikä niitä aina juurikaan ole. Twilio on tästä yksimerkki. API -first tuntuu yleisesti tarkoittavan yritystä, jota voisi ennemmin kutsua nimellä API -only. Ei ole muuta kuin API tai useita apeja niin kuin Twilion tapauksessa 5 apia. Joka tapauksessa näillä data ja toiminnallisia apeja tuottavilla yrityksillä on ollut merkittävä rooli. Niiden avulla muut toimijat ovat voineet tuottaa nopeasti uusia palveluita koostamalla toimintoja eri apeista. On väitetty että muun muassa Lyft ja Shopify ei välttämättä olisi syntynyt jossain Twilion ja Stripen tyyppisiä API ensin yrityksiä olisi syntynyt. Samalla syntyi sitten API-talous, koska APIn käytöstä maksetaan ainakin mainittujen esimerkkien kohdalla.

Design First
Design-first on sitten selkeämpi. APIn muotoilu tehdään ennen toteutusta. Yleensä käytetään nykyään koneluettavia formaatteja APIn kuvailuun. Kuvailu sisältää toiminnallisuuden, käytettävät tietomallit, kutsujen attribuutit ja tunnistuksen. Tätä koneluettavaa kuvausta voidaan suoraan esittää API dokumentaationa ja siten mahdollistaa sen että annetaan API arvioitavaksi ulkopuoliselle kehittäjälle eli potentiaaliselle APIn hyödyntäjälle. Koneluettavasta kuvauksesta voidaan generoida yksinkertainen testirajapinta, jota vasten sitten voidaan tehdä koodia, jonka kautta APIa hyödynnetään. Astutaan siis hyödyntäjän saappaisiin ja kokeillaan miten helppokäyttöinen oma API on ja sopiiko se näppärästi suunniteltuihin käyttötapauksiin. Vasta kun ollaan tyytyväisiä ja homma näyttää toimivalta kaikin puolin, tehdään se toteutus itse APIsta. Syntyvä koneluettava kuvaus on eräänlainen sopimus APIn tuottajan ja hyödyntäjän välillä.

Contract First
Tätä juurikaan ei ainakaan enää käytetä. Enemmän ehkä vain toinen termi Design first ajattelulle, mutta enemmän juristikieltä. Voi toimia paremmin jos design ajattelulle

Code First
Code-First on sitten vastakohta design-first lähestymiselle. Koodataan API ja generoidaan APIn dokumentaatio sitten koodin seassa olevasta kommentoinnista. Tämä on ihan ok toimintatapa, jos kaikki tarpeet on jo hyvin tiedossa ja ollaan varmoilla vesillä. Koodaus on kallista puuhaa ja siksi yhä useammin lähdetään design edellä ettei tehdä turhaa tai vaikeasti muutettavaa toimintaa.

Developer first, vähemmän tunnettu.

Tämä on viimeisen tuttavuuteni ja tätä tulokulmaa on soveltanut muun muassa Stripe ja DocuSign. Tässä ajatus on että ensisijainen asiakas on sovelluskehittäjä ja asiat tehdään hänen silmien kautta. Kehittäjäkokemus on kaiken aa ja oo. Toissijainen asiakas on sitten manageri. Tästä asiasta sitten tuleekin paljon juttua tulevaan Build for Developers kirjaan. Se tulee oleman englanniksi ja lisätietoja löytyy osoitteesta https://buildfordevelopers.com