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