GET

De GET-methode vraagt om overdracht van een huidige geselecteerde representatie voor de doelbron. GET is het primaire mechanisme voor het ophalen van informatie en de focus van bijna alle prestatieoptimalisaties. Wanneer mensen het hebben over het ophalen van identificeerbare informatie via HTTP, bedoelen ze daarom meestal het doen van een GET-verzoek.

Het is verleidelijk om bron-id's te beschouwen als padnamen van externe bestandssystemen en representaties als een kopie van de inhoud van dergelijke bestanden. In feite zijn veel bronnen op die manier geïmplementeerd (zie Paragraaf 9.1 voor gerelateerde beveiligingsoverwegingen). In de praktijk zijn er echter geen beperkingen. De HTTP interface voor een bron kan net zo goed geïmplementeerd zijn als een boom van inhoudsobjecten, een programmatische weergave van verschillende databaserecords of een gateway naar andere informatiesystemen. Zelfs als het URI mapping mechanisme is gekoppeld aan een bestandssysteem, kan een origin server worden geconfigureerd om de bestanden uit te voeren met het verzoek als invoer en de uitvoer te verzenden als de representatie in plaats van de bestanden direct over te dragen. Hoe dan ook, alleen de origin server hoeft te weten hoe elk van zijn resource-id's overeenkomt met een implementatie en hoe elke implementatie erin slaagt een actuele representatie van de doelbron te selecteren en te verzenden in een antwoord op GET.

Een client kan de semantiek van GET wijzigen in een "bereikverzoek", waarbij wordt verzocht om overdracht van slechts een deel of delen van de geselecteerde representatie, door een Range-headerveld in het verzoek op te nemen (RFC7233).

Een payload in een GET-verzoekbericht heeft geen gedefinieerde semantiek; het verzenden van een payload in een GET-verzoek kan ertoe leiden dat sommige bestaande implementaties het verzoek afwijzen.

Het antwoord op een GET-verzoek kan in de cache worden opgeslagen; een cache MAG het gebruiken om te voldoen aan daaropvolgende GET- en HEAD-verzoeken, tenzij anders aangegeven in het headerveld Cache-Control (paragraaf 5.2 van RFC7234).

De GET-methode van het HTTP-protocol kan worden vergeleken met een digitale bibliothecaris. Het vraagt de server beleefd om gegevens te presenteren zonder wijzigingen aan te brengen in de gegevens zelf - een puur passief verzoek.

Wat maakt de GET-methode bijzonder?

1. Consistentie: Stel je voor dat je de bibliothecaris meerdere keren om hetzelfde boek vraagt – je zou elke keer hetzelfde boek krijgen. Hetzelfde geldt voor het GET-verzoek: het levert consequent hetzelfde resultaat.
2. Lezen, niet schrijven: Het GET-verzoek heeft het karakter van een waarnemer. Het bekijkt gegevens maar verandert ze niet.
3. Informatie in de URL: Beschouw de URL als een adres of een indexkaart. Het geeft aan welk boek of welke informatie je zoekt. Maar opgelet: deze kaarten mogen geen privé aantekeningen bevatten, aangezien ze door anderen kunnen worden bekeken.
4. Snelle en efficiënte reacties: Dankzij het vermogen om reacties te cachen, kan de GET-methode snel reageren op herhaalde verzoeken, net als een goed georganiseerde bibliothecaris die precies weet waar elk boek zich bevindt.

Maar er zijn ook beperkingen:

1. Beperkte ruimte voor notities: De URL heeft slechts zoveel ruimte voor informatie. Het is alsof je op een klein indexkaartje schrijft.
2. Geen geheimen: Aangezien URL's zichtbaar zijn en kunnen worden opgeslagen, mag je er geen gevoelige informatie op noteren.
3. Geen interferentie: Een waarnemer beïnvloedt niet wat hij waarneemt. Daarom moet de GET-methode niet worden gebruikt om gegevens te wijzigen. Daarvoor hebben we andere tools in onze digitale gereedschapskist.

Over het geheel genomen is de GET-methode een betrouwbaar en essentieel hulpmiddel in de digitale ruimte, waarmee we informatie efficiënt en veilig kunnen ophalen.