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.
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.
| Dimension | REST | GraphQL | gRPC |
|---|---|---|---|
| Protokoll | HTTP/1.1 + JSON | HTTP/1.1 + JSON | HTTP/2 + Protobuf |
| Dataformat | JSON (text) | JSON (text) | Protobuf (binary) |
| Prestanda | Bra | Bra | Utmärkt |
| Typning | Valfritt (OpenAPI) | Obligatoriskt (Schema) | Obligatoriskt (.proto) |
| Caching | Inbyggd (HTTP) | Komplex (klientside) | Manuell |
| Streaming | SSE (halvduplex) | Subscriptions (WS) | Full duplex |
| Webbläsarstöd | Fullt | Fullt | Via proxy (gRPC-Web) |
| Inlärningskurva | Låg | Medel | Hög |
| Dokumentation | Swagger/OpenAPI | Introspection | Proto-filer + docs |
| Bäst för | CRUD, publika API:er | Komplexa UI, mobil | Microservices, IoT |
| Branschadoption | Dominant (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.
| Verktyg | Typ | Bäst för | Pris |
|---|---|---|---|
| Postman | Testning | REST, GraphQL | Gratis - $14/mån |
| Insomnia | Testning | REST, GraphQL, gRPC | Gratis - $5/mån |
| Swagger/OpenAPI | Dokumentation | REST | Gratis (OSS) |
| Apollo Studio | Schema mgmt | GraphQL | Gratis - Enterprise |
| BloomRPC | Testning | gRPC | Gratis (OSS) |
| Kong | API Gateway | Alla | OSS - Enterprise |
| Hoppscotch | Testning | REST, GraphQL | Gratis (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.