Vad är en API-gateway?

När ni bara har en enda tjänst är det enkelt: den tar emot sina anrop och svarar. Men verkligheten växer. Snart finns flera tjänster bakom kulisserna, och flera appar, partners och system som vill prata med dem. Då uppstår frågan var all den trafiken ska komma in, och hur ni håller ordning på säkerhet och överblick. Svaret är ofta en API-gateway. Här är vad det är.

Liknelsen: receptionisten

Tänk dig ett stort kontor med många avdelningar. Utan reception skulle varje besökare behöva veta exakt vart de skulle, gå rakt in, och varje avdelning skulle själv få kontrollera vilka som kom och gick. Det blir rörigt och osäkert.

Med en reception i entrén blir det ordning. Receptionisten släpper in dem som ska in, visar var och en till rätt avdelning, och för en besökslogg över vilka som passerat. En enda punkt sköter det som annars vore utspritt och svårt att överblicka.

En API-gateway är den receptionisten för era system. Den sitter framför alla bakomliggande tjänster som en gemensam ingång. Alla anrop kommer in där, och gatewayen släpper in de behöriga, styr varje anrop till rätt tjänst och för logg över trafiken. Besökarna – apparna och systemen – behöver bara känna till entrén, inte hur kontoret är organiserat innanför.

Vad gatewayen sköter

Bakom liknelsen ligger några konkreta uppgifter som gatewayen tar hand om på ett ställe, i stället för att varje tjänst ska göra det för sig:

• Autentisering. Gatewayen kontrollerar att den som anropar faktiskt har rätt att göra det, innan anropet ens når tjänsterna bakom. Behörighetskontrollen sker vid dörren, en gång, för allt.
• Hastighetsbegränsning. Den sätter tak för hur många anrop en enskild avsändare får göra under en viss tid. Så skyddas era tjänster från att en enda klient, med flit eller av misstag, dränker dem i förfrågningar. Den avsändaren bromsas utan att övriga drabbas.
• Versionshantering av API:er. När era API:er utvecklas kan gatewayen hjälpa till att styra trafik rätt mellan olika versioner, så att förändringar kan rullas ut utan att allt måste ändras på en gång.

Utöver dessa för gatewayen logg över trafiken, vilket ger överblick och gör det lättare att felsöka när något går snett. Poängen genomgående är densamma: sådant som annars skulle behöva byggas in i varje tjänst samlas till en gemensam plats.

Varför det är bättre än att låta varje tjänst klara sig själv

Man skulle kunna låta varje tjänst hantera sin egen säkerhet, sin egen trafikbegränsning och sin egen loggning. Problemet är att samma logik då måste byggas och underhållas på många ställen. Det blir dyrare, och värre: det görs lätt olika i olika tjänster, eller glöms bort i någon. En bortglömd behörighetskontroll i en enda tjänst är en öppen dörr.

Med en gateway finns den gemensamma logiken på ett ställe, konsekvent för alla. Tjänsterna bakom kan koncentrera sig på sitt egentliga jobb, medan den gemensamma ordningen sköts en gång, samlat och överblickbart. Det gör systemet både säkrare och billigare att förvalta.

När den behövs

En API-gateway är inte alltid rätt. Har ni en enda tjänst och en enda klient som pratar med den, är en gateway ofta överdrift – den lägger till ett lager utan att lösa något verkligt problem.

Nyttan uppstår när det blir fler. Tumregeln är att en gateway lönar sig när ni har fler än en konsument av era API:er – flera appar, partners eller system som anropar er – eller fler än ett par tjänster bakom kulisserna som ska hänga ihop. Då blir den gemensamma ingången det som håller ordning på säkerhet, trafik och överblick när komplexiteten annars skulle springa iväg.

Vi på Weapp bygger API:er och sätter upp gatewayer där de gör nytta, varken mer eller mindre. Vill ni ha ordning på hur era system nås? Titta på våra tjänster eller hör av dig.