Mistä on hyvä API-koodari tehty?

Oletko hyvä API-kehittäjä? Haluatko kehittyä sellaiseksi? Etsitkö kehityskumppania? Tämä blogi on sinulle.

api-koodari.jpg

Kirjoitus sisältää niin törkeän määrän lyhenteitä, että lopusta löytyy selviytymissanasto niille, jotka eivät ihan vielä ole löytäneet sisältään kokenutta API-koodaria.

Määritellään alkuun, mitä tässä kirjoituksessa tarkoitetaan APIlla:

  • Puhutaan REST APIsta ja sen moderneista sukulaisista (mieluummin vähemmän SOAPIsta).
  • APIt eivät ole (pelkästään) integraatioita.
  • APIt eivät ole mitä tahansa softaa, vaan niiden suunnittelua tulee verrata käytettävyys- ja käyttöliittymäsuunnitteluun, sekä tuotesuunnitteluun.

Entä mitä tarkoitamme API-kehittäjällä?

Hyvin kypsynyt API-kehittäjä muotoutuu useamman vuoden jälkeen ohjelmointitaitoiseksi, kommunikaatiokykyiseksi, uudelleenkäytöstä kiinnostuneeksi ja hyvät API-suunnitteluperiaatteet sisäistäneeksi henkilöksi. Hän osaa OpenAPI -speksin ja JSON -skeeman perusasiat ja tietää mistä etsii lisää. Tietoturva ja tietosuoja ovat korkealla prioriteeteissa ja OWASP on lähes raamatun korvike.

Miksi kommunikaatiokykyinen? Koska API-kehittäjän ja/tai API product ownerin on suorastaan pakko keskustella sekä liiketoiminnan että eri teknologioita ja organisaatioita edustavien APIn käyttäjien kanssa tarpeista, joita APIn tulisi täyttää. API on usein yhtä lähellä käyttäjiä kuin käyttöliittymä, ja usein se ainoa käyttöliittymä, jota esimerkiksi kumppanit tai asiakkaiden järjestelmät käyttävät. Eri ”API consumereillä” eli APIa käyttävillä tahoilla voi olla hyvin erilaisia tarpeita.

APIlla on hyvin suuri merkitys niitä käyttävien palveluiden loppukäyttäjien käyttökokemuksessa. Ei ole ihan triviaalia, miten API suunnitellaan ja miten suorituskykyinen se on. API-käyttäjiltä tulee herkästi risuja, mutta myös ruusuja riippuen siitä kuinka helppo API on ymmärtää ja ottaa käyttöön.

Itseaiheutettuun headeriin ei auta pilleri

Teknisestä näkökulmasta API-kehittäjä nauttii kummallisista keskusteluista. Välillä pohditaan, käytetäänkö HTTP-verbejä oikein: ”Äh, pakko tehdä tää hakuendpoint sittenkin POSTilla kun loppuu URIsta tila kesken kun näitä query-parametreja on liikaa”. Tai JSON scheman rakennetta mutustellaan verrattuna liiketoiminnan halutiloihin ja alan standardeihin, kuten pitäisikö schemassa olla productid, ean vai GTIN.

API-koodari saa usein myös headereiden käytöstä ”hedarin” pohtiessaan mikä kannattaa laittaa header-parametriksi ja mikä on se poikkeava tilanne, jolloin kannattaa käyttää custom-headereita. Vinkki: useimmiten ainoastaan lokalisointiin….

Nykyään useimmat API-kehittäjät käyttävät jo sujuvasti muiden API-rajapintoja, joissa autentikointi on hyvässä hapessa tietoturva- ja tietosuojavaatimuksiin nähden (lue: OAuth2 / OpenId Connect). Hyvänkin API-kehittäjän saa tosin toivomaan välillä kylmää Pepsi Maxia tai vihersmoothieta, joita molempia onneksi löytyy läheltä Digian Cofficesta. Yleensä näin käy silloin omassa APIssa pitäisi ko. ratkaisu ottaa käyttöön ja identiteetit ovat firmassa lähinnä hallitussa kriisissä.

Hypertekstinsiirtoyhteyskäytäntöjä, päätepisteitä ja edustustilan siirtoa tukevia sovellusohjelmointirajapintoja – siis että mitä

Jos meidän uusinta API-arkkitehtiamme on uskominen, ei hyvä API-koodari puhu rajapintaa suomeksi. Itselläkin meni kyllä tee väärään kurkkuun ensimmäisellä kerralla kun tiimin konkarit puhuivat sujuvasti ikikieriöistä (ikiluuppi, infinite loop). Joten eiköhän sovita, että API-kehittäjä voi keskittyä englanninkielisiin perustermeihin: http, endpoint ja REST API (representational state transfer application programming interface).

Edellämainitut lyhenteet ja muut tietoliikenteen perusasiat on hyvä oppia mukaan lukien sertifikaatit, domainit, URI-rakenteet, ja että sekä protokollalla että koolla on väliä silloin kun kyseessä on internetin yli API-kutsussa kulkevan payload.

API-kehittäjää auttaa myös API-hallinta-alustojen ymmärtäminen. Ne auttavat huolehtimaan tietoturvan lisäksi muun muassa dokumentaation näyttämisestä, markkinoinnista ja API-käyttäjien tukemisesta ja itsepalvelusta, eli kehittäjäkokemuksesta.

Usein APIt toteutetaan mikropalveluina käyttäen eri pilvi- tai integraatioalustojen jono-, haku-, tallennus- ja muita palveluita hyväksi. Yhä useammin käytetään myös muiden tekemiä API-rajapintoja suoraan tai pilvialustoista valmiina tarjolla olevia konenäkö-, koneoppimis-, chatbot- jne. ”kognitiivisia” palveluja, jotka tarjoavat API-rajapinnat. Jos APIen on tarkoitus toimia mikropalvelukerroksena perinteisten systeemien päällä, voi API-kehittäjä tarvita myös SOAP- ja muita perinteisempiä tekniikoita.

Etsimme jatkuvasti uusia osaajia. Jos mietit mihin suuntaan kehittyä, katso avoimet työpaikat, laita avoin hakemus tai lue lisää meistä. Viimeisiä paikkoja jaossa myös 19.9. Haaga-Helia amk:n ja IBM:n kanssa yhteistyössä toteutettavaan API-seminaariin.

API-seminaari

P.s. jos olet se, jonka pitäisi saada organisaationne API-tekeminen uudelle uralle tai edes käyntiin, ota yhteyttä. Tuotteistettu API Startup- pavelumme saa muutamilla workshopeilla ja koestetuilla menetelmillä API-kehityksenne uudelle tasolle.

Sanasto:

api management





Tilaa blogikirjoitukset sähköpostiisi


Viimeisimmät kirjoitukset



Seuraa meitä somessa

LinkedIn Twitter Facebook YouTube YouTube