Hoppa till innehåll
Cloud

API-integration och arkitektur 2026 - REST, GraphQL eller gRPC?

En komplett guide till moderna API-stilar, arkitekturmönster och säkerhet. Med jämförelsetabell, kodexempel och konkreta rekommendationer för svenska företag.

Simon Axelsson2026-04-0620 min läsning

REST - standarden som dominerar

REST (Representational State Transfer) är fortfarande det absolut vanligaste sättet att bygga API:er. Över 85% av publika API:er använder REST. Det bygger på HTTP-verb (GET, POST, PUT, DELETE) och resursorienterade URL:er.

// REST Exempel - Hämta kunder
GET /api/v1/customers?page=1&limit=20

// Svar
{
  "data": [
    { "id": 1, "name": "Acme AB", "city": "Stockholm" },
    { "id": 2, "name": "Tech Nordic", "city": "Göteborg" }
  ],
  "meta": { "total": 142, "page": 1, "pages": 8 }
}

Styrkor

  • Universellt stödd - varje språk och plattform har HTTP-bibliotek
  • Enkel att cacha med standard HTTP-headers
  • Lätt att förstå och dokumentera (OpenAPI/Swagger)
  • Moget ekosystem med massor av verktyg

Svagheter

  • Over-fetching och under-fetching är vanligt
  • Många endpoints att underhålla för komplexa datamodeller
  • Versionering kan bli plottrigt - /v1, /v2, /v3...

GraphQL - när klienten bestämmer

GraphQL låter klienten definiera exakt vilken data den behöver i en enda förfrågan. Utvecklat av Facebook 2015 och nu använt av GitHub, Shopify, Stripe och tusentals andra.

# GraphQL Exempel - Fråga exakt den data du behöver
query {
  customers(first: 20) {
    id
    name
    city
    orders(last: 3) {
      id
      total
      status
    }
  }
}

Styrkor

  • Klienten bestämmer exakt vilken data den behöver
  • En enda endpoint - enklare än 50 REST-routes
  • Starkt typat schema med inbyggd dokumentation
  • Bättre för mobila klienter (minimal datatransfer)

Svagheter

  • Komplex caching jämfört med REST
  • N+1 query-problem kräver DataLoader
  • Högre inlärningskurva för backend-teamet
  • Fil-upload är krångligare än med REST

gRPC - hög prestanda för microservices

gRPC (Google Remote Procedure Call) använder HTTP/2 och Protocol Buffers för extrem prestanda. Idealiskt för intern microservice-kommunikation där varje millisekund räknas.

// gRPC Proto-definition
syntax = "proto3";

service CustomerService {
  rpc GetCustomer (CustomerRequest) returns (Customer);
  rpc StreamOrders (CustomerRequest) returns (stream Order);
}

message CustomerRequest {
  int32 id = 1;
}

message Customer {
  int32 id = 1;
  string name = 2;
  string city = 3;
}

Styrkor

  • 3-10x snabbare än REST tack vare Protobuf binary serialisering
  • Starkt typade kontrakt med .proto-filer
  • Bi-direktional streaming för realtidskommunikation
  • Inbyggd kodgenerering för 12+ språk

Svagheter

  • Inte nativt stödd i webbläsare (kräver gRPC-Web proxy)
  • Svårt att debugga - binary format är inte människoläsbart
  • Mindre ekosystem och verktyg än REST

Jämförelsetabell - 11 dimensioner

REST vs GraphQL vs gRPC sida vid sida.

DimensionRESTGraphQLgRPC
ProtokollHTTP/1.1 + JSONHTTP/1.1 + JSONHTTP/2 + Protobuf
DataformatJSON (text)JSON (text)Protobuf (binary)
PrestandaBraBraUtmärkt
TypningValfritt (OpenAPI)Obligatoriskt (Schema)Obligatoriskt (.proto)
CachingInbyggd (HTTP)Komplex (klientside)Manuell
StreamingSSE (halvduplex)Subscriptions (WS)Full duplex
WebbläsarstödFulltFulltVia proxy (gRPC-Web)
InlärningskurvaLågMedelHög
DokumentationSwagger/OpenAPIIntrospectionProto-filer + docs
Bäst förCRUD, publika API:erKomplexa UI, mobilMicroservices, IoT
BranschadoptionDominant (85%+)Växande (25%)Nisch (10-15%)

Arkitekturmönster

Tre mönster som komplementerar ert API-val.

API Gateway

Central ingångspunkt som hanterar auth, rate limiting, routing och logging. Använd Amazon API Gateway, Kong eller Azure API Management.

Använd när: När ni har fler än 3 microservices eller behöver centraliserad säkerhet.

Backend for Frontend (BFF)

Separata backend-lager för webb, mobil och tredjepartsklienter. Varje BFF optimerar dataformat och auth för sin klient.

Använd när: När webb och mobilapp har väsentligt olika databehov.

Webhooks

Event-driven arkitektur där system pushar data vid händelser istället för att polla. Implementera med retry-logik och HMAC-signering.

Använd när: Betalningsnotifikationer, CI/CD-pipelines, CRM-synk.

API-säkerhet

Fem krav som måste vara på plats före lansering.

OAuth 2.0 + PKCE

Standard för auktorisering. Använd PKCE för publika klienter (SPA, mobil). Aldrig implicit flow.

API-nycklar med scopes

För server-till-server. Begränsar nyckelns rättigheter till specifika endpoints och metoder.

Rate limiting

Skydda mot DDoS och missbruk. Typiskt 100-1000 requests/minut per klient.

Input validation

Validera ALL input på serversidan. Använd JSON Schema eller Zod. Lita aldrig på klienten.

HTTPS överallt

Kryptera all trafik. Let's Encrypt för cert, HSTS-header för att framtvinga.

Verktygsguide

De bästa verktygen för att bygga, testa och dokumentera API:er.

VerktygTypBäst förPris
PostmanTestningREST, GraphQLGratis - $14/mån
InsomniaTestningREST, GraphQL, gRPCGratis - $5/mån
Swagger/OpenAPIDokumentationRESTGratis (OSS)
Apollo StudioSchema mgmtGraphQLGratis - Enterprise
BloomRPCTestninggRPCGratis (OSS)
KongAPI GatewayAllaOSS - Enterprise
HoppscotchTestningREST, GraphQLGratis (OSS)

Vanliga frågor

Bör vi välja REST eller GraphQL för vårt nya API?

Om ni bygger ett publikt API för tredjepartsutvecklare - REST. Det är universellt förstått och enkelt att dokumentera. Om ni bygger en intern plattform med komplexa datakrav och flera klienttyper - överväg GraphQL. Många organisationer kör båda parallellt.

När är gRPC rätt val?

När ni har microservice-till-microservice-kommunikation där prestanda är kritisk. Särskilt bra för realtidstjänster, IoT och intern kommunikation. Kombination: gRPC internt, REST/GraphQL externt.

Hur hanterar vi API-versioner?

Tre strategier: URL-versioning (/v2/), header-versioning (Accept: application/vnd.api.v2+json) eller query-param (?version=2). För REST: URL-versioning är enklast. För GraphQL: använd @deprecated-direktivet och evolution istället för versionering.

Vilka säkerhetsåtgärder är viktigast?

I prioritetsordning: (1) HTTPS överallt, (2) OAuth 2.0 + PKCE för auth, (3) rate limiting, (4) input validation, (5) API-nycklar med scopes. Implementera alla fem före lansering.