REST, GraphQL och gRPC: välj rätt verktyg

Debatten om API-arkitektur kokar ofta ner till REST kontra GraphQL, men verkligheten är mer nyanserad. Här är vår erfarenhet från produktionsmiljöer:

REST som standardval

REST fungerar för de allra flesta användningsfall. Det bygger på HTTP-standarder som alla utvecklare redan kan, det är enkelt att cacha och övervaka, och verktygsstödet är moget. Om ni inte har en specifik anledning att välja något annat — välj REST.

Nyckeln till bra REST-design är att tänka i resurser snarare än operationer. /orders/123 är en resurs. GET hämtar den, PUT uppdaterar den, DELETE tar bort den. Håll det konsekvent och ni får API:er som är intuitiva att använda.

När GraphQL faktiskt löser ett problem

GraphQL skiner i ett specifikt scenario: när ni har många olika klienter (webbapp, mobilapp, partnerintegrationer) som behöver väldigt olika delmängder av samma data. Istället för att bygga tio REST-endpoints eller ett fett svar som alla klienter filtrerar lokalt, låter GraphQL klienten specificera exakt vilka fält den vill ha.

Men GraphQL kommer med kostnader: svårare caching, risk för N+1-problem i resolvern, och komplex auktorisering per fält. Vi ser regelbundet GraphQL-implementationer som hade varit enklare och snabbare som REST.

gRPC för intern kommunikation

gRPC använder binär serialisering (Protocol Buffers) över HTTP/2 och ger signifikant lägre latens än JSON-baserade protokoll. Det är det naturliga valet för kommunikation mellan mikrotjänster i Kubernetes-kluster där millisekunder spelar roll och alla tjänster ägs av samma organisation.

API-design som håller över tid

Det som skiljer API:er som fungerar i produktion i åratal från dem som skapar kaos efter sex månader är tre saker: versionering, dokumentation och bakåtkompatibilitet.

Versioneringsstrategi

Bestäm tidigt hur ni versionerar. De två praktiska alternativen:

• URI-versionering (/v1/orders, /v2/orders) — tydligt, enkelt att routa, enkelt att övervaka. Rekommenderas för publika och partner-API:er.
• Header-versionering (Accept: application/vnd.opsio.v2+json) — renare URI:er, men svårare att testa i en webbläsare och kräver mer sofistikerad routing.

Det viktigaste beslutet är inte hur ni versionerar, utan att ni har en deprecation policy. Beskriv hur länge gamla versioner lever, hur ni kommunicerar förändringar och vilka SLA:er som gäller för respektive version.

OpenAPI-specifikation som kontrakt

Dokumentera alla API:er med OpenAPI (Swagger) 3.x. Det ger er:

• Autogenererad, alltid aktuell dokumentation
• Klientbibliotek i valfritt språk via kodgenerering
• Kontraktstestning i CI/CD — om specifikationen ändras utan att testerna uppdateras, bryter bygget

Vi ser ofta att team startar med informell dokumentation i Confluence eller README-filer. Det fungerar i tre månader. Sedan är dokumentationen inaktuell och ingen litar på den. OpenAPI-specifikationen lever med koden — det är den enda mekanismen som skalas.

API-gateway: navet i produktion

En API-gateway är inte valfritt i produktionsmiljöer. Den är den centrala kontrollytan för all extern (och ofta intern) API-trafik. Managerade molntjänster

Vad gatewayen hanterar

Vanliga val i AWS och Azure

I AWS-miljöer fungerar Amazon API Gateway väl för serverless-arkitekturer (Lambda-backat) och enklare REST-API:er. För mer avancerade behov — särskilt i Kubernetes-miljöer — är Kong, Envoy (via Istio eller direkt) eller Apigee vanligare.

I Azure fyller Azure API Management en liknande roll med starkt stöd för policy-baserad styrning och utvecklarportaler.

API-säkerhet: vad vi ser i produktion

API:er är den mest utsatta attackytan i moderna applikationer. OWASP API Security Top 10 (2023) listar de vanligaste sårbarheterna, och vi ser dem regelbundet i Opsios SOC. Molnsäkerhet

Autentisering och auktorisering

OAuth 2.0 med OpenID Connect är branschstandard. Implementera det korrekt:

• Använd authorization code flow med PKCE för webbapplikationer — inte implicit flow (deprecated)
• Utfärda korta access tokens (5–15 minuter) med refresh tokens
• Validera scope och claims i varje API-anrop — att ha en giltig token räcker inte, användaren måste ha rätt behörighet för den specifika resursen
• För tjänst-till-tjänst-kommunikation: mTLS eller client credentials flow

Vanliga misstag

Broken Object Level Authorization (BOLA) är det vanligaste API-säkerhetsfelet vi ser. Scenariot: en användare ändrar ID:t i URL:en (/orders/123 → /orders/124) och får tillgång till någon annans data. Lösningen är att alltid kontrollera att den autentiserade användaren har behörighet till den specifika resursen — inte bara att de har en giltig session.

Överdrivet öppna svar är det näst vanligaste. API:et returnerar hela användarobjektet inklusive personnummer, lösenords-hash och interna metadata — trots att klienten bara behöver namn och e-post. Principen om uppgiftsminimering i GDPR gäller även här.

GDPR och NIS2 på API-nivå

Om era API:er hanterar persondata gäller GDPR fullt ut. Konkret innebär det:

• Kryptering i transit: TLS 1.2 som minimum, helst TLS 1.3
• Åtkomstkontroll: dokumenterad behörighetsstyrning per endpoint och datakategori
• Loggning: varje åtkomst till persondata ska vara spårbar
• Uppgiftsminimering: returnera bara de fält som klienten faktiskt behöver

NIS2-direktivet, som nu är implementerat i svensk lag, skärper kraven på incidentrapportering och leveranskedjesäkerhet. Om era API:er exponeras mot externa parter är de en del av leveranskedjan — och omfattas.

Observerbarhet: mät det som spelar roll

Ett API utan observerbarhet är ett API ni inte kan driva. Tre lager av mätning:

Metriker

De fyra gyllene signalerna (från Googles SRE-bok) är minimum:

• Latens — svarstid per endpoint (mät p50, p95, p99 — inte bara medelvärde)
• Trafik — antal requests per sekund
• Fel — andel 4xx och 5xx-svar
• Mättnad — hur nära kapacitetsgränsen backend-tjänsterna är

Loggar

Strukturerade loggar i JSON-format med korrelerings-ID (trace ID) som går genom hela anropskedjan. Utan korrelerings-ID kan ni inte spåra ett enskilt API-anrop genom gateway → tjänst → databas.

Distribuerad spårning

I en mikrotjänstarkitektur passerar ett enda API-anrop potentiellt genom fem till tio tjänster. Utan distribuerad spårning (OpenTelemetry, Jaeger, AWS X-Ray) är det omöjligt att identifiera var latensen uppstår.

Sätt SLO:er (Service Level Objectives) per API. Exempel: "Publika order-API:et ska ha 99,9 % tillgänglighet och p95-latens under 200 ms." Mät mot SLO:erna kontinuerligt och agera på felbudgets. Managerad DevOps

CI/CD och testning för API:er

API:er kräver testning i flera lager:

Kontraktstestning — verifiera att API:et matchar sin OpenAPI-specifikation. Bryt bygget om specifikationen och implementationen divergerar.

Integrationstestning — testa mot faktiska (eller realistiska) beroenden. Mockade tester fångar logikfel men missar nätverks- och konfigurationsproblem.

Lasttestning — kör lasttester som en del av CI/CD, inte bara före release. Verktyg som k6 (Grafana Labs) eller Locust integreras enkelt i pipelines.

Säkerhetstestning — automatiserad DAST (Dynamic Application Security Testing) mot API-endpoints i staging. OWASP ZAP eller Burp Suite i CI/CD-pipelines fångar de vanligaste sårbarheterna. Molnmigrering

API:er som produkt: FinOps-perspektivet

API-trafik genererar kostnader — compute, datatransfer, gateway-anrop. I AWS kostar API Gateway cirka 3,50 USD per miljon REST-anrop. Det låter lite tills ni har 100 miljoner anrop per månad.

Tre åtgärder som minskar API-kostnader utan att försämra prestanda:

1. Caching — CloudFront eller ElastiCache framför frekventa, stabila endpoints kan minska backend-anrop med 60–80 %

2. Komprimering — gzip/brotli på svar minskar datatransferkostnader

3. Rätt compute-modell — serverless (Lambda) för sporadisk trafik, containers (ECS/EKS) för stabil basbelastning

Enligt Flexeras State of the Cloud har kostnadshantering konsekvent rankats som den största molnutmaningen. API-kostnader är en del av den bilden — och ofta den del som växer snabbast eftersom varje ny integration multiplicerar anropsvolymer. Cloud FinOps

Opsios perspektiv: vad vi ser i drift

Från vårt 24/7 SOC/NOC hanterar vi API-relaterade incidenter varje vecka. De vanligaste mönstren:

• Saknad rate limiting — en partners felkonfigurerade klient skickar tusentals anrop per sekund och tar ner backend
• Inget circuit breaker-mönster — ett nedströms API svarar långsamt, och den anropande tjänsten köar upp alla sina trådar tills den också slutar svara
• Otillräcklig loggning — incidenten upptäcks via kundklagomål istället för via monitoring
• Versioneringskaos — tre API-versioner lever parallellt utan tydlig deprecation plan, och ingen vet vilka klienter som använder vilken version

Dessa problem är inte tekniskt komplicerade att lösa. De är organisatoriska: någon måste äga API:et som en produkt, inte som ett sidoprojekt.

Vanliga frågor

Vad är skillnaden mellan REST och GraphQL i praktiken?

REST ger förutsägbara endpoints med en resurs per URI — enkelt att cacha och övervaka. GraphQL låter klienten specificera exakt vilken data den vill ha i ett enda anrop, vilket minskar överflödig dataöverföring men kräver mer komplex backend-logik och gör caching svårare. Välj REST som standard och GraphQL när klienterna har vitt skilda databehov.

Behöver vi en API-gateway?

Ja, så fort ni exponerar API:er utanför ett enda team. En gateway hanterar autentisering, rate limiting, TLS-terminering och observerbarhet centralt. Utan gateway duplicerar varje tjänst den logiken — eller, värre, hoppar över den. AWS API Gateway, Kong och Apigee är vanliga val.

Hur hanterar vi versionering av API:er?

Det vanligaste mönstret är URI-versionering (/v1/orders) för publika API:er. Alternativt fungerar header-baserad versionering för interna tjänster. Det viktigaste är en tydlig deprecation policy: kommunicera i god tid, kör parallella versioner och övervaka trafik till gamla versioner innan ni stänger dem.

Vilka säkerhetskrav gäller för API:er som hanterar persondata?

Under GDPR krävs kryptering i transit (TLS 1.2+), ändamålsenlig åtkomstkontroll och loggning av dataåtkomst. OAuth 2.0 med OpenID Connect är branschstandard för autentisering. Internt bör tjänst-till-tjänst-kommunikation skyddas med mTLS. IMY förväntar sig att ni kan visa att principen om uppgiftsminimering efterlevs — även på API-nivå.

Hur mäter vi om våra API:er fungerar bra i produktion?

Tre grundmått: latens (p50, p95, p99), felfrekvens (4xx/5xx-andel) och throughput (requests per second). Lägg till affärsmått som antal lyckade transaktioner per endpoint. Sätt SLO:er per API — exempelvis 99,9 % tillgänglighet och p95-latens under 200 ms — och mät mot dem med verktyg som Datadog, Grafana eller CloudWatch.

For hands-on delivery in India, see end-to-end konsult consulting.

For hands-on delivery in India, see end-to-end disaster recovery.

For hands-on delivery in India, see end-to-end gcp managed.

For hands-on delivery in India, see end-to-end drift.