API:n elinkaaren hallinta

Esitetty API Camp kurssilla TAMK:ssa 18.1.2017

Transcript

1. API:n elinkaaren hallinta API Camp 18.1.2017 Jarkko Moilanen
2. 1. Analyysi Elinkaaren vaiheet 4. Eläköityminen 2. Kehitys 3. Käyttö
3. Vaihe 1: Analyysi
4. 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
5. • 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
6. Vaihe 1: API Model Canvas http://www.slideshare.net/3scale/api-model-canvas-apidays-mediterranea-2015
7. • 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
8. Vaihe 2: Kehitys
9. • 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
10. 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
11. 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
12. 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 + -
13. Vaihe 3: Käyttö
14. • 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
15. • 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ö
16. 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ö
17. • 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ö
18. Vaihe 4: Eläköityminen
19. 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
20. 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
21. 1. Analyysi Elinkaaren vaiheet 4. Eläköityminen 2. Kehitys 3. Käyttö
22. 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