Upgrade to Pro — share decks privately, control downloads, hide ads and more …

API:n elinkaaren hallinta

API:n elinkaaren hallinta

Esitetty API Camp kurssilla TAMK:ssa 18.1.2017

Jarkko Moilanen, PhD

January 18, 2017
Tweet

More Decks by Jarkko Moilanen, PhD

Other Decks in Business

Transcript

  1. API:n liiketoimintastrategia (miksi tehdään) • Miksi organisaatiomme tarvitsee API:n? •

    Mitä toimintoja sen pitää pystyä tekemään? • Mikä on arvolupaus? • Markkinaselvitys vaikkakin pikaisesti järkevää Vaihe 1: Analyysi
  2. • Mikä on kohderyhmä? • Haluaako kohderyhmä käyttää API:a? Jos

    julkinen API, millaisia ratkaisuja ja palvelua kuvitellaan sen päälle tehtävän? • Onko API osa omaa core tarjontaa? • Onko meillä tarvittavat resurssit ja osaaminen API:n kehittämiseen ja ylläpitoon? • Millaista metriikkaa käytetään analyysissä? Vaihe 1: Analyysi
  3. • Pääsynhallinta: – Rakentavatko kehittäjät muille ihmisille? – Onko järkevää

    käyttää API avaimia, OAuthia tai jotan muuta? – Ulkoinen vai sisäinen toteutus? • Metodit ja protokollat: – Suosiiko kehittäjät REST, SOAP, Thrift, vai jotain muuta? Mikä on tässä kohdin järkevintä? • SDK kielet: – Ovatko kehittäjät Ruby, Python, JS vai jonkun muun käyttäjiä? Mitä SDK:ita tarjotaan ja tuetaan? • Asynkroniset operaatiot: – Hyödynnetäänkö APIa enimmäkseen selainpohjaisisa ratkaisuissa, mobiilisovelluksissa, taustajärjestelmissä? Tuleeko kutsuja palomuurien takaa? Voiko API käyttää webhookkeja? Vaihe 2: Kehitys
  4. • Valitse tyyli 1. Design First – Lähtökohtana koneluettava kuvaus

    (Open API Spec, Swagger, RAML, API blueprint) – koodit, SDK:t ja dokumentaatio generoidaan 2. Code First – koodataan ensin – tehdään kuvaus jälkikäteen Vaihe 2: Kehitys
  5. Design First – Swagger (sitä katsottiinkin edellisellä kerralla) – Online

    ympäristössä swaggerhub.com tai omassa web sovelluksessa (voidaan sisällyttää Github repoon) – Voi harjoitella vapaasti http://editor.swagger.io/ 1. MVP versio ilman koodausta – Generoidaan mockup palvelin tarvittaessa, palaute potentiaalisilta käyttäjiltä 2. Korjaukset 3. Koodin ja testien generointi – viimeistely 4. Dokumentaatio + SDK:t & koodiesimerkkien generointi Palataan tähän päivän lopuksi Vaihe 2: Kehitys
  6. Code First 1. Speksaus old-skool tyyliin 2. Koodataan MVP versio

    – dokumentaatio kommentteina koodin seassa tai ei 3. Palautteen hakeminen ja korjaukset 4. Dokumentaation kirjoitus / irroitus koodista TAI koneluettavan kuvauksen kirjoitus 5. Koodiesimerkkien ja SDK generointi tai tekeminen käsin. Vaihe 2: Kehitys
  7. Vaihe 2: Kehitys Code First Design First • Ehkä sopivampi

    1-miehen tekemiseen • Sisäisen rajapinnan kehittämiseen • Suoraan asiaan eli toteutukseen • Joustavampi tapa • Vähemmän käsityötä, vähemmän ihmisvirheitä • Automaattinen dokumentaatio jota voi tehdä muut kuin koodarit • SDK:t samasta kuvauksesta • Koodiesimerkit samasta kuvauksesta • Versioinnin hallinta • Sisältää autentikoinnin ja tietomallit • Enemmän käsityötä • Määrittely dokumentti erikseen • Opeteltava uusi tapa, kulttuurinen muutos • Automatisoinnin rakentaminen • Muutostenhallinta vaatii enemmän suunnittelua koska koodia generoidaan • Ei löydy työkaluja generointiin ihan kaikille kielille eikä kehikoille • Jotkut kokee liian ohjaavaksi ja rajoittavaksi + -
  8. • API –hallinta on välttämätön jos on muutamakin rajapinta, näitä

    on tullut markkinoille paljon. – palveluna, esim: • 3Scale, Apigee, Mashape, tyk.io – itse hostattuna, esim • Kong, APInf.io, tyk.io (monesti avointa lähdekoodia) Vaihe 3: Käyttö https://apinf.io/ Apinf tuoteomistaja vierailee 1.2.2017
  9. • API –hallinta tarjoaa monesti: – analytiikka ja metriikka käytöstä

    – Dokumentaatio – julkaisuprosessin tuki (deployment) – kehittäjien ”houkuttelu” = kynnys matalaksi, katalogi – Sandbox ominaisuudet API:en testaamiseen – Käytön profilointi + cache – Pääsynhallinta ja käyttäjienhallinta – Liiketoimintamallien tuki – Saavutettavuus (skaalautuva) – Tukee jollain mekanismilla legacy järjestelmiä Vaihe 3: Käyttö
  10. Metriikka on keskeistä! Sitä kautta tiedätte mitä tapahtuu ja missä

    voi parantaa! • Palaavien käyttäjien määrä – koska viimeksi käytti rajapintaa • Liikenteen lähde: tuleeko sisältä vai 3 osapuolen sovelluksesta? • Käytettyjen metodien ryhmittely – kuinka usein kehittäjä käyttää tiettyä metodia toisten metodien rinnalla? • Pyyntöjen mediatyyppi ja määrät: – media tiedostoja, tekstiä? Onko jotain pyydetty selkeästi useammin kuin muita? • Latenssi – kuinka nopeasti palvellaan? Missä on pullonkaulat? • Virhetilanteet – Kuinka usein ja mikä virhe tarkkaanottaen on? Vaihe 3: Käyttö
  11. • Portaali • Evankelisointi • Näkyminen: – tapahtumissa mukana: hackathonit,

    konferenssit, yms • Anna yhteisölle, saat takaisin enemmän • Yhteistyösopimukset • Tuki – näkyvillä myös tukifoorumeilla kuten Stack Overflow, Twitter, ehkä jopa Facebook joskus Vaihe 3: Käyttö
  12. Syyt on moninaisia • Yleisin syy versiointi – youtube, twitter

    • Alla oleva teknologia vanhentuu – skype ja olisiko syy myös Google Hangouts API:n ”sulkemiseen” – Google Maps Data APIn korvasi Google Maps API • Kilpailu (ja siinä häviäminen) tai ei vain kannata syystä tai toisesta • Ei ole riittävää 3 osapuolen kiinnostusta – netflix • Turvallisuus syyt – Google Earth API, SnapChat Vaihe 4: Eläköityminen
  13. Tee hallitus • Suunniteltava • Min 6 kk sopeutumisaika hyödyntäjille

    • Kerro julkisesti -> toitota eri medioissa mitä kohderyhmä seuraa • Helpota siirtymistä pois – jos korvaava rajapinta tee migraatiota varten ohjeet/opas • Blackout testing, eli suunnitellusti hetkeksi töpseli seinästä • Varmista ettet siko käyttöehtoja tai sopimuksia asiakkaiden kanssa Vaihe 4: Eläköityminen
  14. Tehdään taas • Avataan https://editor.swagger.io ja sieltä – File ->

    Open example -> PetStore on Heroku – Käydään läpi esimerkki – Speksi http://swagger.io/specification/ • Tehkää tunnukset Swaggerhub.com palveluun – Tutustukaa palveluun – Linkitetään swaggerhub Github repoon (tarvittaessa tunnukset myös https://github.com – Ensi kerralla tutustutaan swaggeriin syvemmin