Medierade API:er - applikationsarkitektur

I ett modernt digitalt ekosystem, med en stor mängd producenter och konsumenter av tjänster och information, behöver det finnas förutsättningar för ett informationsutbyte. Det finns i dag en tröghet på olika plan mellan konsumenter och producenter som hindrar att informationen att flöda smärtfritt i det digitala ekosystemet. För konsumenter finns utmaningar runt området API:er med, exempelvis, att förstå vad dessa API:er gör och med förståelse och hantering av olika format. För producenter finns, till exempel problem som, alltför många alternativ att utforma API:er på. För att möjliggöra ett effektivt informationsutbyte fyller därför programmeringsgränssnitt för applikationer, så kallade API:er en betydande roll.

Introduktion

Det finns utmaningar vid utveckling/design av API:er för att de ska bli lätta att förstå och använda! Hur kan organisationer hantera och klara av en konsumentcentrerad designprocess för att skapa lättförståeliga API-specifikationer som är konsumerbara?

API:er möjliggör en enkel konsumtion av data och funktionalitet av applikationer, integrationer och partnerekosystem, men kan ibland behöva skyddas och kontrolleras för att förhindra missbruk och avbrott.

API-fiering av äldre och paketerade applikationer räcker vanligen inte för att ansluta dem till moderna gränssnitt och applikationer. Sannolikt kommer de att vara syntaktiskt och semantiskt inkonsekventa med varandra. För att ett API ska vara bli användbart behöver konsumentens behov vara i fokus och då går det inte att tillgängliggöra data och funktionalitet rakt av, utan detta behöver ske med omsorg.

För att organisationer ska kunna bygga bra ekosystem baserade på API:er krävs ordentlig styrning.

Rekommendation

Ansvariga för applikationsarkitektur, utveckling och integration bör därför:

Hantera sina API:er genom att implementera ett förmedlingsskikt (sk. mediation layer) för att förstärka policyer som också klarar av att möta ökade krav på säkerhet och trafik.

Säkerställa att API:er kan skräddarsys utifrån konsumentens behov.

Genom ett medierat API-mönster, skapas förutsättningar för att utöka, förbättra och möjliggöra anpassningar av API:er.

Genom medierade API-tekniker, skapas förutsättningar för att ansluta äldre och paketerade applikationer och för att hantera komplexa integrationsflöden.

En medierad API arkitektur

I ett modernt digitalt ekosystem där en stor mängd aktörer (producenter och konsumenter) bidrar med tjänster och information stöpta i olika komponenter för informationsutbyte, behöver det finnas förutsättningar för ett samskapande mellan offentlig sektor, medborgare och privata aktörer.
För att möjliggöra detta informationsutbyte så spelar exempelvis programmeringsgränssnitt för applikationer, API:er, en stor roll.

För att kunna använda API:er, behöver konsumenter och producenter anta en viss mognadsgrad i termer av förmågor för ökad interoperabilitet. Det finns idag en tröghet på olika plan mellan konsumenter och producenter vilket hindrar informationen att flöda enkelt genom det digitala ekosystemet.

Omfattande användning av API för distribuerade tjänster genererar nya utmaningar att hantera. De kan exponera känslig funktionalitet och information som behöver skyddas, de kan öka nätverkstrafiken som behöver hanteras och öka applikationskomplexiteten, vilket gör övervakning och hantering av servicenivåer mer utmanande.

Delade publika API:er stödjer inte alla potentiella konsumenters specifika behov. i många fall är befintliga API:er till äldre och paketerade applikationer semantiskt och syntaktiskt oförenliga med moderna applikationer. Alla dessa utmaningar leder till en portfölj av applikationer och tjänster som står inför säkerhetsproblem och saknar interoperabilitet - till stor besvikelse för olika intressenter.

Den rekommenderade lösningen är ett förmedlingsskikt för att hantera dessa utmaningar. Det placerar en eller flera medlare mellan en API-konsument och en API-tjänstimplementering. Dessa API-medlare skyddar och kontrollerar åtkomst till API:er- och de förbättrar och möjliggör användning av API:er.

Figuren nedan visar en konceptuell modell för inre och yttre API: er och API-medling.

Visualisering logisk indelning av API:er / Mediation arkitektur - konceptuell modell

Medierad applikationsstruktur beskrivs i flera lager. Det översta lagret är konsumerande applikationer, vilket består av interna och tredjeparts klienter, tjänster och partners. Nästa lager består av yttre API:er där konsumenter finns i olika affärsdomäner och API:erna behandlas som produkter. I mitten av applikationsstrukturen finns det API-medierande lagret som mappar inre och yttre API:er. Olika klientapplikationer kräver olika funktionaliteter. Det fjärde lagret handlar om inre API:er som exponerar domänmodeller. Konsumenter för detta lager finns i samma affärsdomän. Det femte lagret handlar om bakomliggande system och tjänster. I detta lager ingår applikationer, makro-, mini- och mikrotjänster.

Incitament för en medierad API arkitektur

En medierad modell innehåller förutom en konsekvent modell också en konsekvent plats för att specificera policys för alla interaktioner med API:er. Interaktioner med API:er inkluderar olika områden som oftast har olika policys. Interna interaktioner behöver skiljas från externa samt tredjeparts interaktioner och även inkludera förfrågan / svar. Även interaktioner som är av typen meddelandeorienterade och händelsestyrd får en naturlig hemvist i en medierad modell.

För dessa olika områden, med olika policys, följer en rad övriga krav som intressenterna ställer på API:erna. Säkerhet, trafikhantering, övervakning, åtkomst och olika policys för omvandling kan definieras deklarativt och tillämpas på en, flera eller alla API:er. Uppdateringar av policys kan göras lätt, antingen med manuell eller automatisk tillämpning. Det finns också ett behov att kunna skilja på olika sorters anrop som kommer från tjänstens domän, exempelvis från en webb, mobil klient, en annan applikation eller skilja rapporterande verktyg från andra anrop som kommer från andra tjänster som befinner sig inom den aktuella tjänstens domän.

Med en medierad API arkitektur skapas förutsättningar för att policys rörande säkerhet och efterlevnad förstärks och blir mer tydlig. Prestanda och skalbarhet är också två områden som drar fördel genom “routing och lastbalansering”. En logisk indelning enligt en medierad API-arkitektur medför också en förstärkning av användbarheten genom att skilja på inre och yttre API:er. En tjänst kan med fördel exponera ett “inre API” som direkt reflekterar dess domänmodell och en eller flera “yttre API:er” som är skräddarsydda för att möta specifika önskemål och krav från konsumenter utanför.

Se konceptuell bild ovan för mer information kring indelning av API:er i en medierad API arkitektur.

Nyckelfördelar med en medierad API arkitektur

Ökar konsistensen och minskar risken för mänskliga fel vid implementering av åtkomst och säkerhetspolicys.
Minskar utvecklingstiden genom att ta bort komplexiteten att implementera säkerhet och trafikaspekter för varje team som implementerar API:er.
Ökar prestanda, skalbarhet och anpassningsförmåga för systemet överlag
Möjliggör trafikhantering och “throttling” av in och utgående trafik
Möjliggör versionshantering för API:er och anpassade API:er.
Möjliggör monitorering av interaktioner mellan API:er som kan användas för distribuerade applikationer samt uppföljning av SLA överenskommelser.
Möjliggör en grundläggande insamling av mätpunkter som kan användas för att utvärdera effektiviteten av API:er, identifiera brister och aspekter som kräver förbättringsåtgärder och hur man kan uppskatta användning/nytta.

Hur implementerar man en medierad API arkitektur?

Ett lager för medierad arkitektur kan implementeras med en mängd olika tekniker. Den mest kända tekniken för att göra detta är genom en API gateway. Det finns många olika produkter på marknaden för detta, men gemensamt för dem är att de brukar innehålla funktionalitet såsom:

Life cycle API management
Fullständigt system för life cycle API management
Fristående storskaliga / lättviktiga gateways
Integration för att fungera tillsammans med andra molntjänster (iPaaS)
Ingress kontrollers för Kubernetes
Service mesh för Microtjänster

API mediering hjälper dig att anpassa API:er

För konsumenter finns utmaningar runt API området med, exempelvis, att förstå vad dessa API:er gör och med förståelse och hantering av olika format. Tjänster återspeglar vanligtvis API:er som direkt återspeglar en intern domänmodell med processarbetsflöden samt integrerade kommunikationsprotokoll. Konsumenter kräver idag olika nivåer av anpassning till dessa API:er.

Mobilklienter kräver exempelvis ofta ett API som gör det möjligt för appen att samla information som normalt skickas via en enda begäran, istället för att använda ett API som är mer “pratigt” och går igenom en steg-för-steg process. Mobilklienter är ett bra exempel på en klient som ofta behöver delmängder av informationsmodellen.

På grund av sådana behov behöver det vid utveckling/design tas hänsyn till att klienter kan behöva olika tjänstegränssnitt med olika tekniker där också dataformaten ibland kan behöva skilja sig åt. Exempel på tjänstegränssnitt kan vara GraphQL, SOAP eller REST samt exempel på dataformat XML eller JSON. Ibland kan klienten också behöva stöd för ett asynkront mönster i sitt utbyte av information, där API:et som är utvecklat kanske bara har stöd för fråga/svar.