Hur webben fungerar – requests, responses och API:er

Varför du behöver förstå detta

Jamstack är beroende av API:er. Headless CMS levererar innehåll via API:er. Formulär, betalning, sökning – allt hanteras via API:er. Utan en grundläggande förståelse för hur det fungerar är det svårt att felsöka, välja rätt verktyg, eller förstå vad som händer när något går fel.

Den goda nyheten: du behöver inte förstå internets hela infrastruktur. Du behöver förstå tre saker: HTTP-protokollet, JSON och skillnaden mellan REST och GraphQL.

HTTP – webbens transportprotokoll

Varje gång du besöker en webbsida, laddar en bild eller hämtar data från ett API händer samma sak: din browser (eller kod) skickar en request till en server, och servern svarar med en response.

En request har några nyckeldelar:

• Metod: Vad du vill göra. GET hämtar data, POST skickar ny data, PUT/PATCH uppdaterar, DELETE tar bort.
• URL: Adressen till resursen du vill nå.
• Headers: Metadata om requesten – t.ex. autentiseringsnycklar, vilket format du accepterar.
• Body: Data du skickar med (relevant för POST och PUT).

Servern svarar med:

• Statuskod: 200 betyder OK, 404 betyder "hittades inte", 401 betyder "inte autentiserad", 500 betyder serverfel.
• Headers: Metadata om svaret.
• Body: Själva datan – ofta i JSON-format.

JSON – dataformatet du möter överallt

JSON (JavaScript Object Notation) är det dominerande formatet för datautbyte på webben. Det är textbaserat, läsbart för människor och enkelt att hantera i kod.

{
"title": "Min första artikel",
"slug": "min-forsta-artikel",
"published": true,
"author": {
"name": "Simon",
"email": "simon@example.com"
},
"tags": ["webbutveckling", "jamstack"]
}

Det är ett JSON-objekt med strängar, ett booleanskt värde, ett nästlat objekt och en array. De flesta programmeringsspråk kan läsa och skriva JSON med inbyggda funktioner.

Vad är ett API egentligen?

API står för Application Programming Interface. I webbsammanhang är det en URL-adress (eller en uppsättning adresser) som du kan skicka requests till och få strukturerad data tillbaka.

Ett konkret exempel: Sanity (ett headless CMS) har ett API. Om du vill hämta alla blogginlägg från din Sanity-databas skickar du en GET-request till en URL som ser ut ungefär så här:

https://abc123.api.sanity.io/v2024-01-01/data/query/production
?query=*[_type == "post"]

Svaret du får tillbaka är ett JSON-objekt med alla dina inlägg. Din webbplats-kod tar det JSON-objektet och renderar HTML utifrån det.

REST vs GraphQL – två sätt att designa API:er

Du kommer att stöta på båda. Det är värt att förstå skillnaden.

REST (Representational State Transfer)

REST är det traditionella sättet. Varje typ av resurs har sin egen URL:

GET /api/posts          → hämtar alla inlägg
GET /api/posts/42       → hämtar inlägg med ID 42
GET /api/posts/42/comments → hämtar kommentarer till inlägg 42

Enkelt att förstå, vältestat och fungerar med alla HTTP-klienter. Nackdelen: du kan få för mycket eller för lite data. Vill du bara ha titlar på inläggen men API:et alltid returnerar hela inlägget inklusive brödtext, bilder och metadata – det är "over-fetching".

GraphQL

GraphQL löser over- och under-fetching-problemet. Istället för fasta endpoints skickar du en query som specificerar exakt vilken data du vill ha:

query {
posts {
title
slug
publishedAt
author {
name
}
}
}

Du får tillbaka exakt de fälten, inget mer. GraphQL är vanligt i moderna CMS:er (Contentful, Hygraph, Strapi). Det har en brantare inlärningskurva men ger mer flexibilitet, särskilt för komplexa datastrukturer.

Egenskap	REST	GraphQL
Lärtröskel	Låg	Medel
Flexibilitet i datahämtning	Begränsad	Hög
Verktygsekosystem	Moget	Moget men yngre
Debugging	Enkel (browser DevTools)	Kräver GraphQL-klient
Caching	Enkelt (HTTP-caching)	Mer komplex
Vanligt i	De flesta API:er	Moderna CMS:er, GitHub API

Serverlösa funktioner – när du behöver backend-logik

En rent statisk Jamstack-sajt kan inte hantera backend-logik som kräver hemliga nycklar (du vill inte exponera din Stripe-nyckel i frontend-koden). Det löser du med serverlösa funktioner – små kodstycken som körs på servern vid behov, utan att du behöver drifta en hel server.

Vercel och Netlify erbjuder det inbyggt. Du skapar en fil i ett särskilt katalog, och den blir automatiskt en HTTP-endpoint:

// api/contact.js (Vercel)
export default function handler(req, res) {
if (req.method === 'POST') {
const { name, email, message } = req.body;
// Skicka e-post, spara i databas, etc.
res.status(200).json({ success: true });
}
}

Sammanfattning: API:er är kanaler för datautbyte. Du skickar en request (GET, POST, etc.) till en URL och får tillbaka JSON. REST och GraphQL är två sätt att strukturera det på. Serverlösa funktioner fyller gapet när du behöver backend-logik utan att drifta en server.

Nästa steg

Nu när du förstår hur data flödar via API:er är det dags att titta på var innehållet faktiskt bor: headless CMS:er, och hur de skiljer sig från det du kanske är van vid från WordPress.