Wat is een HTTP-verzoek

Structuur van een HTTP-verzoek

Een HTTP-verzoek bestaat uit drie hoofdonderdelen:

1. Request line: Dit omvat de HTTP-methode (werkwoord), het request-target (dat een URI of URL kan zijn) en de HTTP-versie. De HTTP-methode identificeert het type actie dat op de bron moet worden uitgevoerd.

2. Headers: Deze geven aanvullende informatie over het verzoek, zoals de user-agent, cookies, content-length en autorisatietoken. Headers kunnen ook de types data specificeren die de client kan accepteren.

3. Message body: Dit onderdeel is optioneel en wordt gebruikt om data van de client naar de server te sturen of om informatie van de server naar de client te leveren. De message body wordt vaak gebruikt bij het aanmaken of bijwerken van een bron op de server.

Hoe HTTP-verzoeken werken

HTTP-verzoeken zijn de belangrijkste manier van communicatie tussen een client en een server op het World Wide Web. Wanneer je een URL in je browser invoert of op een link klikt, stuurt de browser een HTTP-verzoek naar de server die de website host. De server controleert vervolgens het verzoek en stuurt een HTTP-respons terug, die de gevraagde bron bevat (zoals een HTML-pagina, een afbeelding of een JavaScript-bestand). Deze overdracht van bronnen gebeurt met behulp van het HTTP-protocol, dat de structuur en het formaat definieert van de verzoeken en responsen die worden uitgewisseld tussen de browser en de server.

GET

De GET-methode wordt gebruikt om een bron van een server op te halen. Het is de meest gebruikte HTTP-methode en wordt gebruikt telkens wanneer je op een link klikt of een URL in de adresbalk van je browser typt. GET-verzoeken moeten alleen worden gebruikt om data op te halen en mogen de status van de server niet veranderen.

POST

De POST-methode stuurt data naar de server om een bron aan te maken of bij te werken. De data die naar de server wordt gestuurd, wordt opgeslagen in de request body van het HTTP-verzoek. Dit wordt vaak gebruikt bij het verzenden van formulieren op websites.

PUT

De PUT-methode lijkt op POST in die zin dat het een bron kan aanmaken of bijwerken. Het meerdere keren aanroepen van een PUT-verzoek levert echter altijd hetzelfde resultaat op, terwijl meerdere identieke POST-verzoeken dezelfde bron meerdere keren aanmaken. PUT-verzoeken zijn idempotent, terwijl POST-verzoeken dat niet zijn.

DELETE

De DELETE-methode verwijdert een specifieke bron op de server. Het bevat alle informatie die nodig is om de te verwijderen bron te vinden.

HEAD

De HEAD-methode is identiek aan een GET-verzoek, maar zonder de response body. Dit is handig om meta-informatie over een bron op te halen zonder de volledige inhoud over te dragen. HEAD-verzoeken worden vaak gebruikt om hyperlinks te testen op geldigheid of om te controleren of een bron is gewijzigd.

PATCH

De PATCH-methode past gedeeltelijke wijzigingen toe op een bron. Het lijkt op de PUT-methode maar wordt gebruikt om kleinere wijzigingen aan te brengen, zoals het aanpassen van een enkel veld van een record.

OPTIONS

De OPTIONS-methode beschrijft de communicatieopties voor de doelbron. Hierdoor kan een client de opties en vereisten bepalen die aan een bron zijn gekoppeld zonder deze op te halen.

TRACE

De TRACE-methode voert een message loop-back test uit langs het pad naar de doelbron. Het wordt gebruikt voor debugging-doeleinden.

Elk van deze methoden heeft een specifiek doel bij het communiceren met servers en het manipuleren van bronnen. Door de juiste methode voor elke taak te gebruiken, kunnen ontwikkelaars ervoor zorgen dat hun applicaties correct met servers communiceren.

Request Line

De request line is de eerste regel van een HTTP-verzoek. Het bevat drie belangrijke stukjes informatie:

1. De HTTP-methode (werkwoord) - Dit geeft het type actie aan dat op de bron moet worden uitgevoerd. Veelvoorkomende HTTP-methoden zijn onder andere GET, POST, PUT, DELETE en andere zoals eerder besproken.

2. De request URL - Dit is de URL van de bron waarop de actie moet worden uitgevoerd. Het kan een absoluut pad of een volledige URL zijn.

3. De HTTP-versie - Dit specificeert de versie van het HTTP-protocol dat wordt gebruikt, meestal HTTP/1.1 of HTTP/2.

Hier is een voorbeeld van een request line:

GET /products HTTP/1.1

Request Headers

HTTP-headers stellen de client in staat om aanvullende informatie mee te geven met het verzoek. Headers zijn sleutel-waardeparen gescheiden door een dubbele punt. Enkele veelvoorkomende headers zijn:

• Host - De domeinnaam van de webserver.
• User-Agent - Informatie over de client die het verzoek doet, zoals het browsertype en de versie.
• Content-Type - Het MIME-type van de request body.
• Content-Length - De lengte van de request body in bytes.
• Authorization - Bevat credentials om een user agent bij een server te authenticeren.
• Cookie - Bevat cookies die eerder door de server zijn verzonden.

Hier is een voorbeeld van enkele request headers:

Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.82 Safari/537.36
Content-Type: application/json

Request Body

De request body is optioneel en bevat de data die naar de server wordt gestuurd. Dit wordt meestal gebruikt bij POST-, PUT-, PATCH- en soms DELETE-verzoeken. De data kan in verschillende formaten zijn, zoals:

• Formulierdata - Sleutel-waardeparen verzonden vanuit HTML-formulieren.
• JSON - JavaScript Object Notation, een veelgebruikt formaat voor het verzenden van gestructureerde data.
• XML - eXtensible Markup Language, een ander formaat voor gestructureerde data.
• Binaire data - Zoals afbeeldingen of andere bestanden.

Hier is een voorbeeld van een JSON-payload in een request body:

{
  "name": "John Doe",
  "age": 30,
  "city": "New York"
}

Het begrijpen van de anatomie van een HTTP-verzoek is belangrijk voor webontwikkelaars. Het stelt hen in staat om verzoeken correct te structureren en alle noodzakelijke informatie op te nemen zodat de server ze goed kan verwerken. Het HTTP-verzoek bevat belangrijke informatie zoals de request method, URL, headers en optionele body die de webserver nodig heeft om het verzoek te begrijpen en uit te voeren. Elk HTTP-verzoek opent een TCP-verbinding om het verzoek te verzenden en de respons te ontvangen. HTTP is een applicatielaagprotocol dat deze commandotaal definieert die de apparaten aan beide kanten van de verbinding moeten volgen om te kunnen communiceren.

Beveiligde uitbreiding van HTTP

HTTPS (Hypertext Transfer Protocol Secure) is een uitbreiding van het standaard HTTP-protocol die een beveiligingslaag toevoegt. Het gebruikt bidirectionele encryptie om de communicatie tussen een client en een server te beveiligen. Dit betekent dat alle data die tussen de client en de server wordt uitgewisseld, wordt versleuteld, waardoor het veel moeilijker wordt voor derden om de data te onderscheppen en te lezen.

HTTPS gebruikt SSL (Secure Sockets Layer) of TLS (Transport Layer Security) digitale certificaten aan de serverzijde om beveiligde verbindingen tot stand te brengen. Wanneer een client (meestal een webbrowser) verbinding maakt met een HTTPS-server, presenteert de server zijn SSL/TLS-certificaat om zijn identiteit te bewijzen. De client verifieert vervolgens dit certificaat voordat een versleutelde verbinding wordt opgezet.

Rol van certificaatautoriteiten

SSL/TLS-certificaten worden uitgegeven door vertrouwde derde partijen die bekend staan als certificaatautoriteiten (CA's). De rol van een CA is om de identiteit te verifiëren van de entiteit die het certificaat aanvraagt (meestal de eigenaar van een website of webapplicatie) en om het certificaat te ondertekenen met de eigen private key van de CA.

Wanneer een client een SSL/TLS-certificaat van een server ontvangt, kan het de handtekening verifiëren met behulp van de publieke sleutel van de CA. Als de handtekening geldig is en het certificaat niet is verlopen, kan de client er zeker van zijn dat het communiceert met de echte server en niet met een bedrieger.

Dit proces van het verifiëren van certificaten staat bekend als de SSL/TLS-handshake. Het gebeurt automatisch op de achtergrond wanneer je verbinding maakt met een website via HTTPS. De aanwezigheid van een geldig certificaat en een succesvolle handshake zorgen voor de authenticiteit, integriteit en vertrouwelijkheid van de data die wordt uitgewisseld tussen de client en de server.

CA's spelen een belangrijke rol in het vertrouwensmodel van HTTPS. Zij zijn verantwoordelijk voor het grondig onderzoeken van de entiteiten waaraan zij certificaten uitgeven en voor het behouden van de veiligheid en integriteit van hun eigen ondertekeningssleutels. Webbrowsers en besturingssystemen onderhouden een lijst van vertrouwde CA's, en ze zullen alleen vertrouwde verbindingen opzetten met servers met certificaten die door deze CA's zijn uitgegeven.

Client-servercommunicatie

HTTP-communicatie is gebaseerd op een client-servermodel. De client, meestal een webbrowser, stuurt een HTTP-verzoek naar de server. Het verzoek omvat de URL van de bron, de HTTP-methode (zoals GET, POST, enz.), request headers en soms een request body.

De server verwerkt vervolgens het verzoek en retourneert een HTTP-respons. De respons bevat een statuscode die aangeeft of het ver­zoek succesvol was (bijv. 200 OK) of dat er een fout was (bijv. 404 Not Found). De respons bevat ook headers die aanvullende informatie over de respons geven, en meestal een message body met de gevraagde data.

Wanneer je bijvoorbeeld een URL in je browser invoert, stuurt de browser een GET-verzoek naar de server. De server stuurt vervolgens een respons terug met de HTML-inhoud van de webpagina. De browser parseert deze HTML en stuurt aanvullende verzoeken voor andere bronnen die nodig zijn om de pagina weer te geven, zoals afbeeldingen, CSS-stylesheets en JavaScript-bestanden.

Toegang tot bronnen gehost op verschillende servers

Een enkele webpagina bevat vaak bronnen van meerdere servers. Een pagina kan bijvoorbeeld zijn hoofdinhoud laden van de ene server, zijn afbeeldingen van een andere, en scripts of stylesheets van weer een andere server. Dit komt omdat het internet bestaat uit onderling verbonden servers, die elk hun eigen bronnen hosten.

Wanneer je een webpagina bezoekt, moet je browser afzonderlijke HTTP-verzoeken doen naar elk van deze servers om alle bronnen te krijgen die het nodig heeft om de pagina weer te geven. Het begint met het aanvragen van het HTML-document, dat verwijzingen bevat naar andere bronnen zoals afbeeldingen, CSS en JavaScript-bestanden. De browser doet vervolgens aanvullende HTTP-verzoeken naar de servers die deze bronnen hosten.

Zodra de browser alle noodzakelijke bronnen heeft ontvangen, rendert het de webpagina door de HTML te parsen, de CSS-stijlen toe te passen en eventuele JavaScript-code uit te voeren. Deze JavaScript-code kan verder interacteren met de pagina, de HTML en CSS aanpassen en zelfs aanvullende HTTP-verzoeken doen naar servers (dit is hoe AJAX werkt).

Dus hoewel het misschien lijkt alsof je met één enkele entiteit communiceert wanneer je een website gebruikt, vindt er onder de motorkap een complex netwerk van client-serverinteracties plaats via HTTP.

Verzoeken verzenden en responsen renderen

Webbrowsers zijn de meest voorkomende HTTP-clients. Wanneer je een URL invoert in de adresbalk van een browser of op een link op een webpagina klikt, stuurt de browser een HTTP-verzoek naar de server die de website host. Dit verzoek omvat meestal de URL van de pagina, de HTTP-methode (meestal GET voor normaal surfen op het web) en headers die informatie over de browser geven.

Zodra de server reageert met de gevraagde bronnen, is het de taak van de browser om de inhoud voor de gebruiker te renderen. Voor een typische webpagina betekent dit het parsen van de HTML om het Document Object Model (DOM) te bouwen, het toepassen van CSS-stijlen om de pagina-elementen op te maken en in te richten, en het uitvoeren van JavaScript-code om interactiviteit toe te voegen of de pagina-inhoud dynamisch bij te werken.

Browsers sturen ook meer HTTP-verzoeken voor alle ingebedde bronnen in het HTML-document, zoals afbeeldingen, CSS-bestanden, JavaScript-bestanden of andere gekoppelde inhoud. Elk van deze bronnen heeft een afzonderlijke HTTP-verzoek- en responscyclus nodig.

Browserfuncties en HTTP-verzoeken

Moderne webbrowsers hebben veel functies die HTTP-communicatie optimaliseren:

1. Caching: Browsers kunnen recent opgehaalde bronnen opslaan in een lokale cache. Als dezelfde bron opnieuw nodig is, kan de browser deze uit de cache bedienen in plaats van een nieuw HTTP-verzoek te doen. Dit vermindert netwerkverkeer en maakt het laden van pagina's sneller.

2. Conditionele verzoeken: Browsers kunnen conditionele HTTP-verzoeken sturen, die headers bevatten zoals "If-Modified-Since" of "If-None-Match". Hiermee kan de server alleen een volledige respons terugsturen als de bron is gewijzigd sinds het laatste verzoek, waardoor bandbreedte wordt bespaard als de bron ongewijzigd is.

3. Verschillende request methods: Hoewel de meeste browserverzoeken de GET-methode gebruiken, kunnen browsers andere soorten verzoeken sturen op basis van gebruikersacties. Het indienen van een formulier kan bijvoorbeeld een POST-verzoek sturen, en sommige AJAX-interacties kunnen PUT, DELETE of andere methoden gebruiken.

4. Parallelle verzoeken: Moderne browsers kunnen meerdere HTTP-verzoeken parallel sturen, waardoor pagina's met veel bronnen sneller worden geladen. Er zijn echter limieten aan het aantal gelijktijdige verbindingen dat een browser zal maken naar één enkele server om te voorkomen dat de server wordt overbelast.

5. Beveiligingsfuncties: Browsers hebben ingebouwde beveiligingsfuncties met betrekking tot HTTP, zoals het blokkeren van gemengde inhoud (HTTP-bronnen op HTTPS-pagina's), het afdwingen van CORS-beleid (Cross-Origin Resource Sharing) en het omgaan met cookies en andere authenticatiemechanismen.

Types statuscodes

HTTP-statuscodes worden ingedeeld in vijf klassen, waarbij elke klasse een specifiek type respons vertegenwoordigt:

1. 1xx (Informatief): Deze statuscodes geven aan dat het verzoek is ontvangen en het proces doorgaat. De client kan een definitieve respons verwachten zodra de verzoekverwerking is voltooid. Een voorbeeld is 100 Continue, wat betekent dat de server de verzoekheaders heeft ontvangen en de client de verzoekbody moet sturen.

2. 2xx (Succes): Deze statuscodes betekenen dat het verzoek succesvol is ontvangen, begrepen en geaccepteerd door de server. De meest voorkomende code in deze klasse is 200 OK, wat aangeeft dat het verzoek is geslaagd.

3. 3xx (Omleiding): Deze statuscodes geven aan dat verdere actie door de client moet worden ondernomen om het verzoek te voltooien. Dit omvat meestal het omleiden van de client naar een andere URL. 301 Moved Permanently betekent bijvoorbeeld dat de gevraagde bron permanent is verplaatst naar een nieuwe URL en dat de client deze nieuwe URL moet gebruiken voor toekomstige verzoeken.

4. 4xx (Clientfout): Deze statuscodes worden gebruikt wanneer het verzoek een onjuiste syntax bevat of niet kan worden uitgevoerd vanwege een probleem aan de clientzijde. De bekende 404 Not Found-code behoort tot deze klasse en geeft aan dat de server de gevraagde bron niet kon vinden.

5. 5xx (Serverfout): Deze statuscodes betekenen dat de server een geldig verzoek niet heeft kunnen uitvoeren. Dit duidt meestal op een probleem met de server zelf. De meest voorkomende code in deze klasse is 500 Internal Server Error, een generieke respons wanneer de server een onverwachte situatie tegenkomt die verhindert dat het verzoek wordt uitgevoerd.

Veelvoorkomende statuscodes

Hoewel er veel HTTP-statuscodes zijn, zijn dit enkele van de meest voorkomende:

• 200 OK: Het verzoek is geslaagd. Dit is de standaardrespons voor succesvolle HTTP-verzoeken.

• 201 Created: Het verzoek is vervuld en er is een nieuwe bron aangemaakt als resultaat. Dit is meestal de respons die wordt verzonden na een POST-verzoek.

• 301 Moved Permanently: De gevraagde bron is permanent verplaatst naar een nieuwe URL. Toekomstige verwijzingen naar deze bron moeten de geretourneerde URL gebruiken.

• 400 Bad Request: De server kan het verzoek niet verwerken vanwege een clientfout, zoals een onjuiste verzoeksyntax.

• 401 Unauthorized: Het verzoek vereist gebruikersauthenticatie. De client kan het verzoek herhalen met een geschikte Authorization-header.

• 403 Forbidden: De server begreep het verzoek maar weigert het te autoriseren. Deze status is vergelijkbaar met 401 maar wordt gebruikt wanneer authenticatie niet zal helpen.

• 404 Not Found: De server kan de gevraagde bron niet vinden. Dit kan te wijten zijn aan een verkeerde URL of een bron die is verwijderd.

• 500 Internal Server Error: De server heeft een onverwachte situatie aangetroffen die verhinderde dat het verzoek werd uitgevoerd. Dit is een generieke respons.

• 502 Bad Gateway: De server ontving, terwijl hij als gateway of proxy fungeerde, een ongeldige respons van een upstream-server waartoe hij toegang moest krijgen om het verzoek te voltooien.

• 503 Service Unavailable: De server kan het verzoek momenteel niet afhandelen vanwege een tijdelijke overbelasting of gepland onderhoud. Deze situatie is meestal tijdelijk.

Het begrijpen van deze statuscodes kan enorm helpen bij het oplossen van problemen en het afhandelen van verschillende situaties in je webapplicaties. Bij het ontwerpen van API's is het belangrijk om de juiste statuscodes te gebruiken om het resultaat van het verzoek van een client duidelijk te communiceren. Dit maakt je API begrijpelijker en makkelijker om mee te werken voor andere ontwikkelaars.

Wanneer een client een HTTP-verzoek naar een server stuurt, opent het een TCP-verbinding. De server retourneert vervolgens een respons die een HTTP-statuscode bevat, die de gewenste actie aangeeft die door de browser moet worden uitgevoerd. De responsdata wordt opgeslagen in de body van het HTTP-verzoek, en de Content-Length-header specificeert de grootte van deze data. Verschillende HTTP-methoden zoals GET en PUT worden gebruikt om de gewenste actie aan te geven die door de server moet worden uitgevoerd. Terwijl GET-verzoeken worden gebruikt om data op te halen, zijn PUT-verzoeken idempotent en kunnen ze worden gebruikt om bronnen op de server bij te werken of aan te maken.

Belang van monitoring

Het monitoren van HTTP-verzoeken is belangrijk om ervoor te zorgen dat je webservice goed werkt en clientverzoeken kan uitvoeren. Door HTTP-verzoeken en -responsen bij te houden, kun je snel problemen vinden en oplossen die zich kunnen voordoen. Monitoring helpt je de gezondheid en prestaties van je webapplicatie te behouden en biedt een betere gebruikerservaring voor je clients.

Uptimia gebruiken voor monitoring

Uptimia is een handig hulpmiddel voor het monitoren van HTTP-verzoeken. Het stelt je in staat om afzonderlijke HTTP-verzoekmonitors in te stellen die gedetailleerde responsdata vastleggen. Met Uptimia kun je:

• De HTTP request method selecteren (GET, POST, PUT, DELETE, enz.) voor je monitor
• De URL specificeren die je wilt monitoren
• Het testinterval kiezen waarop de monitor zal worden uitgevoerd
• De testlocaties selecteren vanwaar de HTTP-verzoeken worden verzonden

Je kunt ook geavanceerde verzoeksinstellingen configureren zoals headers, queryparameters, cookies en request body. Deze flexibiliteit stelt je in staat om realistische scenario's te simuleren en je webservice grondig te testen. Je kunt hier meer lezen over websitemonitoring.

Waarschuwingen instellen

Om problemen snel te vinden en op te lossen, is het belangrijkom waarschuwingen in te stellen in je monitoringsysteem. Met Uptimia kun je waarschuwingen aanmaken die worden geactiveerd wanneer aan bepaalde voorwaarden wordt voldaan, zoals:

• HTTP-responsstatuscodes in het 4xx-bereik (clientfout) of 5xx-bereik (serverfout)
• Responstijd die een opgegeven drempelwaarde overschrijdt
• Onverwachte inhoud in de response body
• SSL/TLS-certificaatverlopen of validatiefouten

Door waarschuwingen in te stellen, kun je ervoor zorgen dat je snel wordt gewaarschuwd wanneer zich problemen voordoen, zodat je ze snel kunt oplossen. Dit helpt downtime te minimaliseren en een hoge servicekwaliteit voor je gebruikers te behouden.

Het monitoren van HTTP-verzoeken is niet alleen belangrijk voor het vinden en oplossen van problemen, maar ook voor het verkrijgen van inzicht in de prestaties en gebruikspatronen van je webapplicatie. Door de data te analyseren die door je monitoringtool is verzameld, kun je geïnformeerde beslissingen nemen om je applicatie te optimaliseren, zoals:

• Prestatieknelpunten vinden en verwijderen
• Infrastructuur schalen om verhoogd verkeer aan te kunnen
• Cachingstrategieën verbeteren om responstijden te verminderen
• Database-queries of API-aanroepen optimaliseren