HTTP als protocol

Elke pagina die je opent, elke knop die data ophaalt, elk formulier dat je verstuurt: het gaat allemaal via HTTP. Het is het protocol waarin je als webontwikkelaar het meest zal lezen, schrijven en debuggen.

Het goede nieuws: HTTP is opvallend eenvoudig. Het is tekst. Een request is een paar regels die zeggen wat je wil, een response is een paar regels die zeggen hoe het afliep, gevolgd door de gevraagde inhoud. Alles wat je in de Network tab ziet, is een variatie op die twee berichten.

Waar HTTP zit in het geheel

HTTP is een applicatieprotocol. Het bouwt op alles wat je in de vorige lessen zag:

Laag	Wat er gebeurt	Meer daarover
Applicatie	HTTP: wat je wil en wat je terugkrijgt	deze pagina
Beveiliging	TLS: hetzelfde bericht, versleuteld	HTTPS & TLS
Transport	TCP op poort 80 of 443	TCP/IP, Poorten
Internet	IP: adressering en routering	IP-adressering

Voor het eerste HTTP-byte vertrekt, is er dus al een naam opgezocht via DNS, een TCP-verbinding opgezet en meestal ook een TLS-handdruk afgerond. HTTP is de laatste stap, niet de eerste.

Eén request, één response

HTTP werkt strikt tussen een client en een server:

• De client (browser, app, curl, Postman, je eigen code) neemt het initiatief en stuurt een request.
• De server wacht, verwerkt en stuurt een response terug.

Op elk request volgt exact één response. Ook een foutmelding is een response: 404 is een antwoord, geen stilte.

HTTP is stateless

De server onthoudt tussen twee requests niets over jou. Elk verzoek staat volledig op zichzelf, ook al komen ze een fractie van een seconde na elkaar. Dat je toch ingelogd blijft, komt door cookies, en die bouwen daar bovenop. Zie Cookies, sessions & CORS.

Anatomie van een request

Een request bestaat uit vier onderdelen:

Onderdeel	Voorbeeld	Wat het zegt
Methode	GET	Wat de client wil doen
URL	/posts/1	Met welke resource
Headers	Accept: application/json	Extra informatie over het verzoek
Body	(leeg bij GET)	De meegestuurde gegevens

Als tekst over de lijn ziet dat er zo uit:

GET /posts/1 HTTP/1.1
Host: jsonplaceholder.typicode.com
Accept: application/json
User-Agent: curl/8.1.2

De eerste regel heet de startlijn: methode, pad en versie. Daaronder de headers, één per regel. Dan een lege regel, en pas daarna een eventuele body.

Anatomie van een response

Een response bestaat uit drie onderdelen:

Onderdeel	Voorbeeld	Wat het zegt
Statuscode	200 OK	Hoe het afliep
Headers	Content-Type: application/json	Wat je krijgt en hoe ermee om te gaan
Body	{ "id": 1, ... }	De inhoud zelf

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 292

{
  "userId": 1,
  "id": 1,
  "title": "sunt aut facere..."
}

Dezelfde opbouw als bij het request: één statuslijn, dan headers, dan een lege regel, dan de body.

Drie manieren om precies hetzelfde te zien

Tool	Sterkte	Wanneer
DevTools Network tab	Toont alles wat je pagina zelf doet, met timing en initiator	Debuggen van je eigen frontend
curl	Ruw en exact: je ziet letterlijk elke regel die over de lijn gaat	Snel testen, scripts, servers zonder browser
Postman	Overzichtelijk klikken: methode, headers, body, en een geschiedenis	Een API verkennen of documenteren

Met curl -v zie je beide berichten na elkaar. De regels met > verstuur je, de regels met < komen terug:

curl -v https://jsonplaceholder.typicode.com/posts/1

> GET /posts/1 HTTP/1.1
> Host: jsonplaceholder.typicode.com
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Type: application/json; charset=utf-8
<
{ "userId": 1, "id": 1, "title": "sunt aut facere..." }

Twee testservers die je dit semester nog vaak zal gebruiken

• jsonplaceholder.typicode.com – een nep-API met posts, users en todo's. Je mag er alles op uitproberen, ook POST en DELETE.
• httpbin.org – kaatst je eigen request terug als JSON. Ideaal om te zien wat je nu écht verstuurde.

Welke versie van HTTP?

Versie	Transport	Belangrijkste verschil
HTTP/1.1	TCP	Eén request tegelijk per verbinding; leesbare tekst
HTTP/2	TCP	Meerdere requests door elkaar over één verbinding, binair verpakt
HTTP/3	QUIC over UDP	Geen blokkade meer bij één verloren pakket

De concepten op deze pagina's, methode, URL, headers, statuscode en body, blijven in alle drie identiek. Wij gebruiken HTTP/1.1 als referentie omdat je die als tekst kan lezen.

Bron: HTTP messages – MDN Web Docs, Mozilla Contributors, CC BY-SA 2.5.

Test jezelf

1. Je stuurt één request en de server heeft veel data. Hoeveel responses krijg je?

2. Wat betekent het dat HTTP stateless is?

3. In welke volgorde gebeuren deze stappen bij het openen van `https://example.com`?

Wat leer je in dit hoofdstuk?

Sectie	Wat je leert
URI's en URL's	Hoe een webadres opgebouwd is en welk deel waar terechtkomt
HTTP-methoden	GET, POST, PUT, PATCH en DELETE, en hoe je de juiste kiest
Statuscodes	Wat 2xx, 3xx, 4xx en 5xx je vertellen over waar het misloopt
HTTP-headers	De metadata die elk bericht begeleidt
JSON, REST & clientverzoeken	Hoe API's data uitwisselen en hoe je zelf een verzoek opbouwt
Cookies, sessions & CORS	Ingelogd blijven op een stateless protocol, en waarom je fetch() geblokkeerd wordt

Onthoud

• HTTP is een applicatieprotocol in leesbare tekst, bovenop TCP (poort 80) of TLS (poort 443).
• Een request bestaat uit methode, URL, headers en body; een response uit statuscode, headers en body.
• Op elk request volgt exact één response.
• HTTP is stateless: elk verzoek staat op zichzelf.
• curl -v, de Network tab en Postman tonen alle drie hetzelfde verkeer, in een andere verpakking.