HTTP-responses zijn een belangrijk onderdeel van webcommunicatie, waarmee servers kunnen reageren op verzoeken van clients met de gevraagde gegevens, statusinformatie en andere belangrijke details. Dit artikel legt de structuur en onderdelen van een HTTP-response uit, inclusief de statusregel, headers en body. We bekijken de verschillende groepen HTTP-statuscodes en hun betekenis, met praktische voorbeelden om te laten zien hoe ze worden gebruikt. We bespreken ook goede manieren om HTTP-responses te verwerken in webontwikkeling, zowel aan de client-side als server-side, om goede communicatie tussen clients en servers te waarborgen.
Belangrijkste punten
- Een HTTP-response is het bericht dat een webserver terugstuurt naar een client nadat deze een HTTP-verzoek heeft ontvangen en verwerkt.
- Belangrijke onderdelen van een HTTP-response zijn de statusregel, headers en een optionele body met de gevraagde content.
- HTTP-statuscodes zijn onderverdeeld in informatieve responses (1xx), succesvolle responses (2xx), omleidingsberichten (3xx), client-foutresponses (4xx) en server-foutresponses (5xx).
- Aan de client-side is het belangrijk om statuscodes te controleren, responsegegevens te verwerken op basis van de Content-Type header, en omleidingen en fouten goed af te handelen.
- Aan de server-side zijn het instellen van de juiste statuscodes en headers, het geven van duidelijke foutmeldingen, en het implementeren van goede foutafhandeling en logging noodzakelijk voor webontwikkeling.
Wat is een HTTP-response?
Een HTTP-response is het bericht dat een webserver terugstuurt naar een client nadat deze een HTTP-verzoek heeft ontvangen en verwerkt. Het levert het resultaat van het verzoek van de client, of dat nu een succes is, een fout of iets daartussenin. De response bevat statusinformatie over het verzoek en kan ook content bevatten in de body, zoals de gevraagde bron (een webpagina, afbeelding, JSON-gegevens, etc.) of een foutmelding.
HTTP-responses zijn nodig voor een client om te begrijpen of hun verzoek succesvol was of niet en wat het resultaat van dat verzoek was. Webbrowsers gebruiken HTTP-responses om te weten welke content ze aan gebruikers moeten tonen. API's gebruiken HTTP-responses om het resultaat van bewerkingen aan te geven en gegevens terug te sturen. De structuur en content van de HTTP-response bepalen hoe de client verder gaat.
Onderdelen van een HTTP-response
Een HTTP-response bestaat uit verschillende belangrijke onderdelen:
- Statusregel: De eerste regel van de response, die de HTTP-versie, een statuscode en een statusbericht bevat.
- Headers: Sleutel-waarde paren die extra informatie geven over de response, zoals het contenttype, contentlengte, cache-instructies en meer.
- Body (optioneel): De daadwerkelijke content van de response, zoals HTML, JSON, een afbeelding, etc.
Hier is een voorbeeld van een eenvoudige HTTP-response:
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1234
<!DOCTYPE html>
<html>
<head>
<title>Voorbeeldpagina</title>
</head>
<body>
<h1>Hallo, wereld!</h1>
<p>Dit is een voorbeeldpagina.</p>
</body>
</html>
Praktijkvoorbeelden
Webbrowsen: Wanneer je een URL invoert in je webbrowser, stuurt deze een HTTP-verzoek naar de server. De server reageert vervolgens met een HTTP-response die de HTML-content van de webpagina bevat. Je browser gebruikt deze response om de pagina weer te geven.
API-interactie: Wanneer een applicatie een verzoek doet naar een API-endpoint, reageert de API-server met een HTTP-response. Deze response bevat vaak JSON-gegevens die de applicatie kan gebruiken. Een weer-app kan bijvoorbeeld een verzoek doen naar een weer-API en actuele weergegevens ontvangen in de response.
Bestand downloaden: Wanneer je op een link klikt om een bestand te downloaden, stuurt je browser een HTTP-verzoek naar de server. De server reageert met een HTTP-response die de bestandsgegevens in de body bevat en headers die het bestandstype en de grootte aangeven.
Onderdelen van een HTTP-response
Een HTTP-response heeft verschillende belangrijke onderdelen die informatie geven over de uitkomst van het verzoek en de gevraagde gegevens leveren.
Statusregel
De statusregel is de eerste regel van de HTTP-response. Deze bevat:
- HTTP-versie: Toont de gebruikte HTTP-protocolversie, zoals HTTP/1.1 of HTTP/2.
- Statuscode: Een driecijferig nummer dat het resultaat van het verzoek aangeeft, zoals 200 voor succes, 404 voor "niet gevonden" of 500 voor een serverfout.
- Statustekst: Een korte beschrijving van de statuscode, zoals "OK" voor 200, "Not Found" voor 404 of "Internal Server Error" voor 500.
Hier zijn enkele veelvoorkomende HTTP-statuscodes en hun betekenis:
| Statuscode | Statustekst | Betekenis |
|---|---|---|
| 200 | OK | Het verzoek was succesvol en de response body bevat de gegevens. |
| 201 | Created | Het verzoek was succesvol en er is een nieuwe bron aangemaakt. |
| 301 | Moved Permanently | De gevraagde bron is permanent verplaatst naar een nieuwe URL. |
| 400 | Bad Request | De server kon het verzoek niet begrijpen vanwege ongeldige syntaxis. |
| 401 | Unauthorized | Het verzoek vereist gebruikersauthenticatie. |
| 404 | Not Found | De server kon de gevraagde bron niet vinden. |
| 500 | Internal Server Error | De server heeft een onverwachte fout aangetroffen. |
De HTTP-statuscode maakt deel uit van het responsebericht. Het definieert de klasse van de response en speelt een categoriserende rol. Het eerste cijfer van de statuscode geeft het type response aan:
- 1xx: Informatieve response
- 2xx: Succes
- 3xx: Omleiding
- 4xx: Client-fout
- 5xx: Server-fout
HTTP-statuscodes zijn uitbreidbaar, maar HTTP-applicaties hoeven niet de betekenis van alle geregistreerde statuscodes te begrijpen. Extra informatie over de response is te vinden in de response header-velden.
Response headers
Na de statusregel volgen de response headers. Dit zijn sleutel-waarde paren die meer details geven over de response. Enkele veelvoorkomende headers zijn:
- Server: Het servertype dat de response heeft gegenereerd, zoals "Apache/2.4.41 (Ubuntu)".
- Content-Type: Het MIME-type van de gegevens in de response body, zoals "text/html" voor HTML of "application/json" voor JSON.
- Content-Length: De grootte van de response body in bytes.
- Cache-Control: Instructies voor cachemechanismen, die aangeven of de response kan worden gecachet, voor hoe lang, etc. Bijvoorbeeld, "max-age=3600" betekent dat de response één uur kan worden gecachet.
- Set-Cookie: Stuurt cookies van de server naar de client, zoals "session_id=abc123; Expires=Wed, 21 Jun 2023 07:28:00 GMT".
Lege regel
Na de headers is er een lege regel. Deze lege regel geeft het einde van de headers-sectie van de response aan.
Response body
Na de lege regel komt de response body. Deze bevat de daadwerkelijke gegevens die werden aangevraagd, zoals:
Een HTML-bestand voor een webpagina:
<!DOCTYPE html> <html> <head> <title>Voorbeeldpagina</title> </head> <body> <h1>Welkom op de voorbeeldpagina</h1> <p>Dit is een voorbeeld van een HTML response body.</p> </body> </html>JSON-gegevens voor een API-response:
{ "name": "Jan Jansen", "age": 30, "city": "Amsterdam" }Een afbeelding, video of ander mediabestand.
Een bestand om te downloaden, zoals een PDF of ZIP-archief.
Als de response een fout aangeeft, zoals een 404- of 500-statuscode, kan de body een foutmelding bevatten met meer details over het probleem, zoals:
<!DOCTYPE html>
<html>
<head>
<title>404 Niet gevonden</title>
</head>
<body>
<h1>404 Niet gevonden</h1>
<p>De gevraagde bron kon niet worden gevonden op deze server.</p>
</body>
</html>
De response body is optioneel. Voor sommige verzoeken, zoals een HEAD-verzoek of een 204 "No Content"-response, is er geen body.
HTTP-response statuscode-categorieën
HTTP-response statuscodes zijn onderverdeeld in vijf categorieën op basis van hun eerste cijfer. Elke categorie vertegenwoordigt een andere klasse van responses.
Informatieve responses (100-199)
Statuscodes in het bereik 100-199 betekenen dat de server het verzoek heeft ontvangen en aan het verwerken is. Dit zijn informatieve responses. Enkele veelvoorkomende informatieve statuscodes zijn:
| Statuscode | Beschrijving |
|---|---|
100 Continue |
De server heeft de request headers ontvangen en de client moet de request body verzenden. |
102 Processing |
De server heeft het verzoek ontvangen en is het aan het verwerken, maar er is nog geen response beschikbaar. |
Voorbeeldscenario:
- Een client stuurt een POST-verzoek met een grote payload. De server reageert met een
100 Continue-statuscode om de client te vertellen dat deze de request body moet verzenden.
Succesvolle responses (200-299)
Statuscodes in het bereik 200-299 betekenen dat de server het verzoek heeft ontvangen, begrepen en geaccepteerd. Enkele veelvoorkomende succesvolle statuscodes zijn:
| Statuscode | Beschrijving |
|---|---|
200 OK | Het verzoek is geslaagd en de response body bevat de gevraagde gegevens. |
201 Created |
Het verzoek is geslaagd en er is een nieuwe bron aangemaakt. Dit wordt vaak gebruikt als response op een POST-verzoek. |
204 No Content |
De server heeft het verzoek voltooid maar hoeft geen content terug te sturen. |
Voorbeeldscenario's:
- Een client vraagt een webpagina op met een GET-verzoek. De server reageert met een
200 OK-statuscode en stuurt de HTML-content terug. - Een client stuurt een formulier in om een nieuwe bron aan te maken met een POST-verzoek. De server maakt de bron aan en reageert met een
201 Created-statuscode. - Een client stuurt een DELETE-verzoek om een bron te verwijderen. De server verwijdert de bron en reageert met een
204 No Content-statuscode.
Omleidingsberichten (300-399)
Statuscodes in het bereik 300-399 betekenen dat de client meer actie moet ondernemen om het verzoek te voltooien. De actie kan door de user agent worden uitgevoerd zonder interactie met de gebruiker. Enkele veelvoorkomende omleidingsstatuscodes zijn:
| Statuscode | Beschrijving |
|---|---|
301 Moved Permanently |
De gevraagde bron heeft een nieuwe permanente URI gekregen en toekomstige verwijzingen moeten een van de teruggegeven URI's gebruiken. |
302 Found |
De gevraagde bron bevindt zich onder een andere URI. De client moet de Request-URI blijven gebruiken voor toekomstige verzoeken. |
304 Not Modified |
De bron is niet gewijzigd sinds de versie die is opgegeven in de request headers, dus de client kan de gecachte versie blijven gebruiken. |
Voorbeeldscenario's:
- Een client vraagt een bron op die permanent is verplaatst naar een nieuwe URL. De server reageert met een
301 Moved Permanently-statuscode en voegt de nieuwe URL toe aan deLocation-header. - Een client vraagt een bron op die zich onder een andere URL bevindt. De server reageert met een
302 Found-statuscode en voegt de tijdelijke URL toe aan deLocation-header. - Een client stuurt een voorwaardelijk GET-verzoek met een
If-Modified-Since-header. Als de bron niet is gewijzigd sinds de opgegeven datum, reageert de server met een304 Not Modified-statuscode.
Client-foutresponses (400-499)
Statuscodes in het bereik 400-499 betekenen dat de client een fout lijkt te hebben gemaakt. Behalve bij het reageren op een HEAD-verzoek, moet de server een entiteit toevoegen die de fout uitlegt. Enkele veelvoorkomende client-foutstatuscodes zijn:
| Statuscode | Beschrijving |
|---|---|
400 Bad Request |
De server kon het verzoek niet begrijpen vanwege verkeerde syntaxis. |
401 Unauthorized |
Het verzoek vereist gebruikersauthenticatie. |
404 Not Found |
De server heeft niets gevonden dat overeenkomt met de Request-URI. |
Voorbeeldscenario's:
- Een client stuurt een verzoek met ongeldige of ontbrekende parameters. De server reageert met een
400 Bad Request-statuscode en voegt een foutmelding toe aan de response body. - Een client probeert toegang te krijgen tot een beschermde bron zonder geldige authenticatie. De server reageert met een
401 Unauthorized-statuscode en vraagt de client om te authenticeren. - Een client vraagt een bron op die niet bestaat op de server. De server reageert met een
404 Not Found-statuscode.
Server-foutresponses (500-599)
Statuscodes in het bereik 500-599 betekenen dat de server weet dat deze een fout heeft gemaakt of het verzoek niet kan uitvoeren. Behalve bij het reageren op een HEAD-verzoek, moet de server een entiteit toevoegen die de fout uitlegt, en of het een tijdelijke of permanente situatie is. Enkele veelvoorkomende server-foutstatuscodes zijn:
| Statuscode | Beschrijving |
|---|---|
500 Internal Server Error |
De server heeft een onverwachte situatie aangetroffen waardoor het verzoek niet kon worden voltooid. |
503 Service Unavailable |
De server kan het verzoek momenteel niet verwerken vanwege tijdelijke overbelasting of onderhoud van de server. |
504 Gateway Timeout |
De server heeft, terwijl deze als gateway of proxy fungeerde, geen tijdige response ontvangen van de upstream server die nodig was om het verzoek te voltooien. |
Voorbeeldscenario's:
- Een client vraagt een bron op, maar er treedt een onverwachte fout op aan de serverzijde. De server reageert met een
500 Internal Server Error-statuscode en logt de fout voor onderzoek. - Een client probeert toegang te krijgen tot een service die tijdelijk niet beschikbaar is vanwege onderhoud. De server reageert met een
503 Service Unavailable-statuscode en kan eenRetry-After-header toevoegen om aan te geven wanneer de service naar verwachting weer beschikbaar is. - Een client vraagt een bron op waarvoor de server moet communiceren met een upstream server. Als de upstream server er te lang over doet om te reageren, stuurt de server een
504 Gateway Timeout-statuscode naar de client.
Voor meer informatie over HTTP-statuscodes kun je de volgende bronnen raadplegen:
HTTP-responses verwerken in webontwikkeling
Bij het maken van webapplicaties moet je HTTP-responses goed verwerken, zowel aan de client-side als server-side. Dit helpt om een goede gebruikerservaring te maken en helpt bij het debuggen en onderhouden van de applicatie.
Client-side
Aan de client-side, zoals in een webbrowser of een mobiele app, moet je:
Statuscodes controleren: Na het verzenden van een HTTP-verzoek moet de client de HTTP-statuscode van de response controleren om te zien of het verzoek werkte of niet. Bijvoorbeeld:
Statuscode Betekenis 200 OK Succes 404 Gevraagde bron niet gevonden Responsegegevens verwerken: Op basis van de statuscode en het
Content-Type-header-veld moet de client de response body op de juiste manier verwerken. Bijvoorbeeld:Content-Type Actie HTML Browser zal het weergeven JSON Parsen naar een object voor verder gebruik Omleidingen en fouten afhandelen: Als de statuscode een omleiding betekent (3xx-codes), moet de client de nieuwe URL in de
Location-header volgen. Voor client-fout (4xx) en server-fout (5xx) codes moet de client foutmeldingen tonen aan de gebruiker en mogelijk het verzoek opnieuw proberen of de gebruiker vragen iets te doen.
Voorbeeld van het verwerken van een HTTP-response bericht in JavaScript met de Fetch API:
fetch('https://api.example.com/data')
.then(response => {
if (!response.ok) {
throw new Error(`HTTP fout! status: ${response.status}`);
}
return response.json();
})
.then(data => {
console.log(data);
// Verwerk de gegevens
})
.catch(error => {
console.error('Fout:', error);
// Handel de fout af
});
Server-side
Aan de server-side moet je:
De juiste statuscodes en headers instellen: Bij het verzenden van een response moet de webserver de juiste HTTP-statuscode instellen om het resultaat van het verwerken van het verzoek aan te geven. Deze moet ook response header-velden bevatten, zoals
Content-Type, om de client te helpen de response goed te begrijpen.Duidelijke foutmeldingen geven: Voor client- en server-foutresponses moet de server een duidelijke en korte foutmelding in de response body opnemen. Dit helpt ontwikkelaars te begrijpen wat er mis ging en hoe het op te lossen.
Goede foutafhandeling en logging implementeren: Op de server is het belangrijk om fouten goed op te vangen en af te handelen. Dit betekent fouten loggen voor latere analyse en debugging, en geen gevoelige gegevens tonen in foutmeldingen die naar de client worden gestuurd.
Voorbeeld van het verzenden van een HTTP-response in Node.js met Express:
app.get('/data', (req, res) => {
try {
const data = getDataFromDatabase();
res.status(200).json(data);
} catch (error) {
console.error('Fout:', error);
res.status(500).json({ error: 'Internal Server Error' });
}
});
