DIGIKOM
API Management skapar säkerhet, kontroll och nya möjligheter kring API:er och WebServices till era system
Björn Wallin
Vad är menas med Tjänst resp API?• Tjänst (Service)
– Väldefinierad funktion som tillgängliggör data och funktionalitet och kan adresseras och anropas (remote) på ett standardiserat sätt i en tjänsteorienterad arkitektur (SOA). (Ejbegränsat till web services/SOAP!)
– Kan (men behöver inte) vara HTTP-baserade
• Application Programming Interface (API)– Specifikation på hur program (motsvarande) anropas/används– Kan (men behöver inte) vara HTTP-baserade
• Web Services är (enligt W3C) XML-baserade internet-API:er (typiskt SOAP)• Representational State Transfer (REST) är ett (jämfört med SOAP) enklare sätt
att implementera tjänster direkt baserat på HTTP-protokollet
Vad är menas med Tjänst resp API?• En Tjänst (Service) har ett gränssnitt, d v s ett API• Web Services är internettjänster med XML-baserat API:er• REST-tjänster har API:er baserade på HTTP-protokollets sätt att
adressera resurser.• Det finns även tjänster med andra typer av gränssnitt/API:er, men
SOAP-baserade Web Services och REST-API:er är de dominerande typerna.
• I SOA-/integrationssammanhang kan begreppen tjänst, service och API oftast användas synonymt
Vad är menas med Tjänst resp API?• Skilj på API (gränssnitt) och implementation (applikation)• Ett API kan implementeras och tillhandahållas/exponeras av:
– Verksamhetssystem– Fristående (web-) applikationer (t ex Java, DotNet, PHP)– Applikationer i integrationsplattformar (t ex Mule)– Med mera…
• API:et kan (ska) vara oförändrat även om implementationen förändras eller byts ut helt.
• Olika livscykler, version 2.3.1 av applikationen kan fortfarande exponera version 1.0 av API:et
Varför API:er?• Det vi vill uppnå med API:er (generellt):
– Lös koppling– Utbytbarhet
• Skilj på:– API (gränssnittspecifikation)– Implementation (applikation)
Klient Klient Klient
API
Implementation
System System
Stabilt!
Förändra
Lägg till / Ta bort / Byt ut / Uppgradera
Opåverkade
Varför API:er?• Ett vanligt misstag är att spegla bakomliggande systems funktionalitet
och datamodell i API:et– Förändring i eller byte av system kommer med därmed att påverka API:et och
klienterna.
• Utforma API:et utifrån generaliserad funktionalitet och generaliserad data.
– Idealt en helt generell och standardiserad (kanonisk) datamodell
API-led Connectivity“The Next Step in the Evolution of SOA”
API-led connectivity is the integration approach that will provide the speed organizations are looking for. It provides an approach for connecting and exposing assets. With this approach, companies can deliver today’s projects faster than ever before while also building an infrastructure to increase productivity on future projects and an enterprise ready for change.
API-led Connectivity• MuleSoft förespråkar
integrationer via fleraAPI-skikt
API-led Connectivity• Process-skiktet
– Verksamhetsorienterade tjänster(ex: Lägg order, sök kund, skicka faktura, etc)
– Även sammansatta tjänster(ex: Lägg order inkl skapa kund)
– Idealt med kanoniska datamodeller enligt ovan
API-led Connectivity• System-skiktet
– Primärt implementera API:er mot system somsaknar egna (bra) API:er.
– Inga krångliga systemspecifika kopplingar iprocess-skiktet. Lösa en gång och återanvändavia system-API.
– Vill tillämpa API-management funktionalitetsom t ex behörighet.
• Även proxa befintliga API:er för att nyttja API-Manager
– Även hantera t ex behörighet mot backend-system på ett ställe.• Kanske externt, klient-certifikat, kryptering o dyl
API-led Connectivity• Experience-skiktet
– Det som är mest nytt i MuleSofts modell
– Anpassa API efter klient, mer lättanvänt ochändamålsenligt. T ex sammansatta operationer,mindre datamängder, färre dynamiska argument…
– Andra policies mm i API-manager.T ex externt experience-API på internt process-API.
– Annars många gånger utmärkt att använda process-skiktet direkt.
API-led Connectivity• Tre skikt med HTTP-API:er plus system-
koppling är ett potentiellt prestandaproblem.
• Tillämpa modellen friare, betrakta som logiska skikt, inte strikt HTTP-API.
• Utöver HTTP kan varje skikt även ha andra ingångar som VM (intern Java), synkrona (icke-persistenta) JMS-köer, mm. Samma operationer och datamodell.
• Tappar API-management-funktionalitet!
API-led Connectivity• Genom att bygga tjänster/API:er mot affärsobjekt och system får vi
över tid en mängd återanvändbara resurser att bygga tillämpningar på.
• Nya sammansatta/anpassade API:er kan snabbt byggas på befintliga API:er för att möta nya behov.
• Ger flexibilitet, kvalitetssäkring och sparar tid (=minskar kostnader)
API-led Connectivity• Vi bygger ett applikationsnätverk!
API-led Connectivity• En pionjär:
– Stort logistikföretag
– Slutet 90-talet (före web services och SOA som känt begrepp)
– Funktionalitet skulle ut på webben (boka transporter, söka försändelser, o s v)
• Princip:– All webbifierad funktionalitet skulle byggas som återanvändbara tjänster som kunde
anropas över http med väldefinierade standardiserade gränssnitt. Lade grunden för ett applikationsnätverk!
API-led Connectivity• Att bygga och använda ett applikationsnätverk kräver (bl a):
– Kontroll på användning• Vem använder vad?• Behörighet• SLA:er• Belastning• Mm
– Kunskap och verktyg för att hitta, använda och bygga API:er• API-dokumentation/register (API-portaler)• Testmöjligheter• Verktyg för design och implementation av API:er
API-Management Självservice: ICC/Center of Excellence (CoE) Center for Enablement (C4E)
API-Management• Exponera (ofta proxa) API:er via en API-Gateway• Där appliceras regler på API:erna via administrativt gränssnitt
– Styra åtkomst (inloggning, API-nyckel)– Tillämpa SLA:er– Begränsa trafik
• API-register med versionshantering• Kontroll på API-användning
– Klientapplikationer– Anropsstatistik - > analysmöjligheter– Larm
• API-portaler – dokumentation och åtkomst för klienter
API-ManagementMuleSoft Anypoint Platform
API-ManagementProxa befintliga API:er:
• Peka ut API, Mule proxy-applikation genereras.• Ger management-funktionalitet på befintliga API:er och möjlighet till
alternativa exponeringsvägar.• T ex skapa ett managerbart system-API på ett befintligt API i ett
verksamhetssystem,• eller ett externt behörighetsstyrt API ovanpå ett internt process-API.
• Se upp! Att proxa ”as is” ger inte lös koppling.
API-ManagementApplicera regler, s k policies, exempel:• Rate limiting: Begränsa antalet anrop per tidsenhet (avvisa)• Throttling: Begränsa, sätt anrop i kö• IP black/white-list• Kräv registrering av klienter och API-nyckel• Knyt policies och klienter till SLA-nivåer• Kräv inloggning:
– LDAP– OATH
• Custom: Definiera egna policies (Mule-flows), tillgängliga för applicering via API-mgr
API-ManagementAPI-register och portaler:
• Alla API:er och versioner registreras i API-manager -> API-register
• Kan skapa privat (intern/inloggning) eller publik utvecklarportal för varje API/version där API:erna kan dokumenteras till valfri nivå.
– Inklusive API-specifikation med testmöjligheter
• Via portaler kan klienter ansökan om tillgång
API-ManagementStatistik, analys och larm:
• Alla anrop registreras
• Standardiserade och anpassningsbara sammanställningar för analys– Anrop per klient, länder, plattformar; andel lyckade/fel, o s v
• Larm– I API-manager (API-ägare/administratörer) och via epost (intressenter)– T ex om anrop bryter mot policies, hög belastning/låg prestanda, felkoder i returen
API-ManagementDemo…
API-Management• API-manager en del i Anypoint Platform a k a Mule Enterprise
• Alternativ för Mule Community?– Pulsen har valt WSO2