Web-APIt <ul><li>Suunnittelu </li></ul><ul><li>Toteutus </li></ul>
Agenda <ul><li>Lyhyesti Exovesta </li></ul><ul><li>Web-API:t </li></ul><ul><ul><li>Määritelmiä </li></ul></ul><ul><ul><li>...
<ul><li>Exove toimittaa innovatiivisia, luotettavia ja liiketoimintalähtöisiä web-palveluita, jotka auttavat asiakkaitamme...
<ul><li>Lähtökohtamme on asiakkaamme strategia ja tarpeet, jotka jalkautamme verkkopalveluiksi. </li></ul>
Palvelumme Strategia Ohjaus Toteutus Internet-strategian konsultointi Yrityksen strategian jalkautus verkkoon Palvelusuunn...
Web-APIt
Rajauksia <ul><li>Tässä esityksessä puhutaan web-sivustojen ja  -palvelujen tarjoamista API:sta </li></ul><ul><ul><li>Ovat...
Määritelmiä <ul><li>Tämän esityksen kannalta web-rajapintoja on kahta erilaista tyyppiä </li></ul><ul><li>URL-pohjainen  <...
Toiminta perusperiaatteiltaan <ul><li>Palvelu tarjoaa API:n joukolle sovelluksia </li></ul><ul><li>Käyttäjä ottaa sovelluk...
Autentikointi ja auktorisointi <ul><li>Palveluilla on erilaisia tarpeita käyttäjien autentikoinnille ja auktorisoinnille <...
 
Siirrettävän tiedon määrä <ul><li>Web-ympäristössä ei ole takeita kaistasta tai latenssista </li></ul><ul><ul><li>Parasta ...
Rajapintojen granulaarisuus <ul><li>Tiedon sopiva “raekoko” vaihtelee riippuen sekä palvelun että siihen kytkeytyvän sovel...
Rajapintojen granulaarisuus / sisäkkäisyys API 1 API 2 API 3 API 4 Sovellus1 (UI) Sovellus 2 (m2m)
Nimeämiskäytännöt <ul><li>Rajapinnan olisi hyvä olla yhdenmukainen nimeämiseltään </li></ul><ul><li>Jos rajapinta on REST-...
 
Versiointi <ul><li>Palvelun kehittyessä ja kasvaessa nykyiset API:t saattavat vanhentua osittain tai kokonaan </li></ul><u...
 
Dokumentointi <ul><li>Hienokaan API ei ole minkään arvoinen, jos sillä ei ole käyttäjiä </li></ul><ul><li>Kehittäjille täy...
 
Käyttöönottoa tukevia asioita <ul><li>Valmiit kirjastot ja koodiesimerkit nopeuttavat API:a käyttävien ohjelmistojen tekoa...
 
Kehittäjälle kelpaavat krouvimmatkin mekanismit <ul><li>API:in liittyvät ohjelmalliset tukitoiminnot, kuten API-avaimen py...
 
Muita huomioita
Tehokkuus <ul><li>Jos palvelu on todella suosittu, API voi muodostua suorituskykyongelmaksi </li></ul><ul><ul><li>Kannatta...
Sisäisestä API:sta julkiseksi <ul><li>Mikäli palvelussa käytetään paljon AJAX-toiminnallisuuksia, kannattaa niitä varten r...
API:t monikanavaisuuden sivutuotteena <ul><li>Mikäli järjestelmä pystyy tuottamaan sisältöä monikanavaisesti, se voi tuott...
Kiitoksia ajastanne
Upcoming SlideShare
Loading in...5
×

WOA: Web APIt

1,014

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,014
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

WOA: Web APIt

  1. 1. Web-APIt <ul><li>Suunnittelu </li></ul><ul><li>Toteutus </li></ul>
  2. 2. Agenda <ul><li>Lyhyesti Exovesta </li></ul><ul><li>Web-API:t </li></ul><ul><ul><li>Määritelmiä </li></ul></ul><ul><ul><li>Tiedon granulaarisuus ja nimeämiset </li></ul></ul><ul><ul><li>Dokumentointi </li></ul></ul><ul><li>Muita huomioita </li></ul>
  3. 3. <ul><li>Exove toimittaa innovatiivisia, luotettavia ja liiketoimintalähtöisiä web-palveluita, jotka auttavat asiakkaitamme tekemään parempaa bisnestä verkossa </li></ul>
  4. 4. <ul><li>Lähtökohtamme on asiakkaamme strategia ja tarpeet, jotka jalkautamme verkkopalveluiksi. </li></ul>
  5. 5. Palvelumme Strategia Ohjaus Toteutus Internet-strategian konsultointi Yrityksen strategian jalkautus verkkoon Palvelusuunnittelu Sivustosuunnittelu Käyttöliittymäsuunnittelu Sivustojen ja palvelujen toteutus Julkaisujärjestelmät Palvelujen optimointi Kävijöiden seuranta ja analysointi
  6. 6. Web-APIt
  7. 7. Rajauksia <ul><li>Tässä esityksessä puhutaan web-sivustojen ja -palvelujen tarjoamista API:sta </li></ul><ul><ul><li>Ovat siis osa suurempaa kokonaisuutta </li></ul></ul><ul><ul><li>Esimerkiksi Amazon Associates Web Service tai Google Maps API </li></ul></ul><ul><li>API:a käytetään joko toisesta ohjelmasta tai web-sivulta JavaScriptillä </li></ul><ul><li>Esitys ei ota kantaa webissä / pilvessä toimiviin ajoympäristöihin </li></ul><ul><ul><li>Google App Engine, Amazon EC2 </li></ul></ul><ul><ul><li>Näissä omat API:t ja toimintamallit </li></ul></ul>
  8. 8. Määritelmiä <ul><li>Tämän esityksen kannalta web-rajapintoja on kahta erilaista tyyppiä </li></ul><ul><li>URL-pohjainen </li></ul><ul><ul><li>Metodikutsu on HTTP GET tai POST johonkin osoitteeseen </li></ul></ul><ul><ul><li>Palvelin vastaa XML:llä tai JSON:lla </li></ul></ul><ul><ul><li>Sekä selain (JavaScript) tai erillinen ohjelma voivat toimia asiakkaana </li></ul></ul><ul><li>JavaScript-pohjainen </li></ul><ul><ul><li>API tarjotaan JavaScript-kirjastona, metodikutsut ja paluuarvot ovat JavaScriptin metodeja ja olioita </li></ul></ul><ul><ul><li>Voidaan käyttää vain selaimesta </li></ul></ul>
  9. 9. Toiminta perusperiaatteiltaan <ul><li>Palvelu tarjoaa API:n joukolle sovelluksia </li></ul><ul><li>Käyttäjä ottaa sovelluksen käyttöönsä </li></ul><ul><li>Sovellus ottaa yhteyttä palveluun </li></ul><ul><ul><li>Autentikointi käyttäjän antamilla tiedoilla, jos on tarve </li></ul></ul><ul><ul><li>Syntyy sessio </li></ul></ul><ul><li>Sovellus kutsuu palvelun metodeja ja saa takaisin palvelun tuottamaa tietoa </li></ul>
  10. 10. Autentikointi ja auktorisointi <ul><li>Palveluilla on erilaisia tarpeita käyttäjien autentikoinnille ja auktorisoinnille </li></ul><ul><ul><li>Valittava oikea menetelmä tilanteen mukaan </li></ul></ul><ul><li>Yleisimmin käytetään API-avaimia </li></ul><ul><ul><li>Käyttäjä syöttää avaimen käyttämiinsä sovelluksiin </li></ul></ul><ul><ul><li>Koko API avoinna yhdellä avaimella, avain ei vaihdu </li></ul></ul><ul><li>Esimerkiksi O Auth tarjoaa fiksumman mekanismin </li></ul><ul><ul><li>Token-pohjainen pääsy tiettyihin resursseihin </li></ul></ul><ul><ul><li>Autentikointi tapahtuu API:n tarjoavan palvelun kirjautumisen kautta </li></ul></ul><ul><li>Vastaavia mekanismeja toteutettu API-kohtaisesti </li></ul>
  11. 12. Siirrettävän tiedon määrä <ul><li>Web-ympäristössä ei ole takeita kaistasta tai latenssista </li></ul><ul><ul><li>Parasta on aina varautua pahimpaan </li></ul></ul><ul><li>Tiedon ja kyselyiden määrä täytyy optimoida </li></ul><ul><ul><li>Ei saa siirtää turhaa tietoa (erityisesti duplikaatit ja laskettavissa olevat asiat) </li></ul></ul><ul><ul><li>Toisaalta, ei saa jättää olennaista tietoa siirtämättä </li></ul></ul><ul><ul><li>Valittava oikea protokolla </li></ul></ul><ul><ul><li>API voi tarjota erilaisia vastaussettejä </li></ul></ul><ul><li>JavaScript-API:ssa voidaan käyttää selainta välimuistina </li></ul><ul><ul><li>Tieto tosin katoaa helposti sivulatausten välissä </li></ul></ul><ul><ul><li>Google Gears ja HTML5 tuovat aikanaan pysyvän paikallisen välimuistin </li></ul></ul>
  12. 13. Rajapintojen granulaarisuus <ul><li>Tiedon sopiva “raekoko” vaihtelee riippuen sekä palvelun että siihen kytkeytyvän sovelluksen toiminnasta </li></ul><ul><ul><li>Käyttöliittymävetoiset sovellukset tarvitsevat valmiimmaksi pureskeltua tietoa kuin m2m – ratkaisut </li></ul></ul><ul><ul><li>Väärä granulariteetti johtaa helposti bisneslogiikan siirtymiseen väärään paikkaan </li></ul></ul><ul><ul><li>Liian matalan tason operaatiot johtavat jatkuvaan höpinään </li></ul></ul><ul><ul><li>Liian korkean tason operaatiot taas saattavat estää sovellusta toimimasta haluamallaan tasolla tai reverse engineering -ratkaisuihin </li></ul></ul>
  13. 14. Rajapintojen granulaarisuus / sisäkkäisyys API 1 API 2 API 3 API 4 Sovellus1 (UI) Sovellus 2 (m2m)
  14. 15. Nimeämiskäytännöt <ul><li>Rajapinnan olisi hyvä olla yhdenmukainen nimeämiseltään </li></ul><ul><li>Jos rajapinta on REST-tyylinen, pyyntöjen URL:t kannattaa nimetä ihmisille luettaviksi </li></ul><ul><li>JavaScript-API:n nimeämisessä toimitaan kuten normaaleissa ohjelmistorajapinnoissa </li></ul><ul><li>Palautetuissa olioissa tai muissa tietorakenteissa selkeys on valttia </li></ul>
  15. 17. Versiointi <ul><li>Palvelun kehittyessä ja kasvaessa nykyiset API:t saattavat vanhentua osittain tai kokonaan </li></ul><ul><ul><li>Tämä on syytä ottaa huomioon heti kättelyssä API-rakennetta suunniteltaessa </li></ul></ul><ul><li>Jokainen tarjottu API olisi hyvä versioida </li></ul><ul><ul><li>Esimerkiksi lisäämällä versio HTTP-polkuun </li></ul></ul><ul><li>Vanhan ja uuden version pitäisi toimia yhtä aikaa </li></ul><ul><ul><li>Päällekkäisen ajan pituus riippuu palvelusta, API:n käytöstä ja toimialasta </li></ul></ul>
  16. 19. Dokumentointi <ul><li>Hienokaan API ei ole minkään arvoinen, jos sillä ei ole käyttäjiä </li></ul><ul><li>Kehittäjille täytyy tarjota riittävä dokumentaatio API:n käytöstä </li></ul><ul><ul><li>Sekä ohjeistus että referenssit </li></ul></ul><ul><ul><li>Esimerkkikoodia </li></ul></ul><ul><li>Wikit ja muut osallistavat mediat helpottavat kehittäjiä parantamaan dokumentaatiota ja auttamaan toisiaan </li></ul>
  17. 21. Käyttöönottoa tukevia asioita <ul><li>Valmiit kirjastot ja koodiesimerkit nopeuttavat API:a käyttävien ohjelmistojen tekoa </li></ul><ul><li>Testaus täytyy ratkoa erikseen ja dokumentoida hyvin </li></ul><ul><ul><li>Osassa palveluista voidaan käyttää normaalia tunnusta testaamiseen </li></ul></ul><ul><ul><li>Toisissa pitää olla erillinen testi-API, joka ei aiheuta epätoivottuja vaikutuksia (veloituksia, kustannusten syntyä, yksityisten tietojen siirtymistä, yms.) </li></ul></ul><ul><li>Jatkuva kommunikointi pitää mielenkiintoa yllä </li></ul><ul><li>V i katilanteisiin on syytä puuttua nopeasti </li></ul>
  18. 23. Kehittäjälle kelpaavat krouvimmatkin mekanismit <ul><li>API:in liittyvät ohjelmalliset tukitoiminnot, kuten API-avaimen pyytäminen voidaan toteuttaa melko yksinkertaisen näköisenä </li></ul><ul><li>Paukut kannattaa laittaa ensiksi itse API:n viilaamiseen kuntoon </li></ul><ul><li>Periaatteessa REST-tyylinen API voisi samalla tarjota omat käyttöönoton mekanisminsa </li></ul><ul><ul><li>Dokumentaatiossa olisi linkit tarvittaviin metodeihin, joita kutsuttaisiin suoraan selaimella ja tulos voitaisiin kopioida leikepöydän kautta omaan ohjelmaan </li></ul></ul>
  19. 25. Muita huomioita
  20. 26. Tehokkuus <ul><li>Jos palvelu on todella suosittu, API voi muodostua suorituskykyongelmaksi </li></ul><ul><ul><li>Kannattaa jo alkuvaiheessa valita järkevä protokolla ja muut tiedon siirtoon liittyvät yksityiskohdat </li></ul></ul><ul><ul><li>XML:n sarjallistaminen työlästä ja lisäarvoa ei välttämättä paljoakaan </li></ul></ul><ul><ul><li>JSON toimii hyvin JavaScriptille, mutta muilla ei suurta etua </li></ul></ul><ul><ul><li>Oma protokolla kannattaa tehdä vasta pakkoraossa </li></ul></ul><ul><li>JavaScript kannattaa kompressoida ja pakata </li></ul><ul><ul><li>Täytyy tosin testata hyvin tarkkaan eri selaimilla </li></ul></ul>
  21. 27. Sisäisestä API:sta julkiseksi <ul><li>Mikäli palvelussa käytetään paljon AJAX-toiminnallisuuksia, kannattaa niitä varten rakentaa jollakin tavalla koherentti API </li></ul><ul><ul><li>Tästä API:sta on helppo lähteä liikenteeseen myöhemmin julkisen API:n luonnissa </li></ul></ul><ul><ul><li>Refaktorointitarve voi tosin johtaa yhteensopivuusongelmiin oman sivuston kanssa </li></ul></ul><ul><ul><li>Toimeliaat käyttäjät saattavat ryhtyä käyttämään sisäistä API:a omin neuvoin </li></ul></ul>
  22. 28. API:t monikanavaisuuden sivutuotteena <ul><li>Mikäli järjestelmä pystyy tuottamaan sisältöä monikanavaisesti, se voi tuottaa myös XML:ää </li></ul><ul><ul><li>API toteutetaan siis view-kerroksen avulla </li></ul></ul><ul><ul><li>Ei tarvitse toteuttaa kahta kertaa </li></ul></ul><ul><ul><li>Kaikkea ei tosin välttämättä voida toteuttaa kovin helposti tai tehokkaasti </li></ul></ul>
  23. 29. Kiitoksia ajastanne

×