GET

HTTP-metode

Specifikation af HTTP-metoden GET

GET-metoden anmoder om overførsel af en aktuel valgt repræsentation for målressourcen. GET er den primære mekanisme til informationssøgning og fokus for næsten alle optimeringer af ydeevnen. Når folk taler om at hente nogle identificerbare oplysninger via HTTP, henviser de derfor generelt til at lave en GET-anmodning.

Det er fristende at tænke på ressourceidentifikatorer som eksterne filsystem-stinavne og på repræsentationer som en kopi af indholdet af sådanne filer. Det er faktisk sådan, mange ressourcer er implementeret (se afsnit 9.1 for relaterede sikkerhedsovervejelser). I praksis er der dog ingen sådanne begrænsninger. HTTP-grænsefladen for en ressource kan lige så godt implementeres som et træ af indholdsobjekter, en programmatisk visning af forskellige databaseposter eller en gateway til andre informationssystemer. Selv når URI-tilknytningsmekanismen er knyttet til et filsystem, kan en oprindelsesserver være konfigureret til at udføre filerne med anmodningen som input og sende outputtet som repræsentation i stedet for at overføre filerne direkte. Uanset hvad er det kun originalserveren, der behøver at vide, hvordan hver af dens ressourceidentifikatorer svarer til en implementering, og hvordan hver implementering formår at vælge og sende en aktuel repræsentation af målressourcen i et svar på GET.

En klient kan ændre semantikken i GET til at være en "range request", der kun anmoder om overførsel af nogle dele af den valgte repræsentation, ved at sende et Range header-felt i anmodningen ([RFC7233]).

En payload i en GET-anmodningsbesked har ingen defineret semantik; at sende en payload-body på en GET-anmodning kan få nogle eksisterende implementeringer til at afvise anmodningen.

Svaret på en GET-anmodning kan caches; en cache KAN bruge det til at tilfredsstille efterfølgende GET- og HEAD-anmodninger, medmindre andet er angivet af Cache-Control-headerfeltet (afsnit 5.2 i [RFC7234]).

Svaret på en GET-anmodning er cachebart.

HTTP-metode GET er blevet specificeret i afsnit 4.3.1 i dokument RFC 7231 af Internet Engineering Task Force (IETF) og World Wide Web Consortium (W3C).

Beskrivelse af GET-metoden

GET metoden i HTTP-protokollen kan sammenlignes med en digital bibliotekar. Den spørger høfligt serveren om at præsentere data uden at ændre på selve dataene – det er en rent passiv forespørgsel.

Hvad gør GET metoden speciel?

  1. Konsistens: Forestil dig at spørge bibliotekaren om den samme bog flere gange – du ville få den samme bog hver gang. Det samme gælder for GET-anmodningen: den leverer konsekvent det samme resultat.
  2. Læs, ikke skriv: GET-anmodningen har en observatørkarakter. Den ser på data, men ændrer det ikke.
  3. Information i URL'en: Betragt URL'en som en adresse eller et registerkort. Det angiver, hvilken bog eller information du søger efter. Dog bør man være forsigtig: disse kort bør ikke indeholde private noter, da de kan ses af andre.
  4. Hurtige og effektive svar: Takket være evnen til at cache svar kan GET metoden hurtigt besvare gentagne anmodninger, meget lig en velorganiseret bibliotekar, der præcist ved, hvor hver bog er placeret.

Men der er også begrænsninger:

  1. Begrænset plads til noter: URL'en har kun så meget plads til information. Det er som at skrive på et lille registerkort.
  2. Ingen hemmeligheder: Da URL'er er synlige og kan gemmes, bør du ikke skrive nogen følsomme oplysninger på dem.
  3. Ingen indblanding: En observatør påvirker ikke det, de observerer. Derfor bør GET metoden ikke bruges til at ændre data. Der er andre værktøjer i vores digitale værktøjskasse til det.

Overordnet set er GET metoden et pålideligt og essentielt værktøj i det digitale rum, der hjælper os med at hente information effektivt og sikkert.

Eksempel på HTTP-metoden GET

Request header:
GET /data HTTP/1.1
Host: api.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko)Chrome/58.0.3029.110 Safari/537
Accept: application/json
Accept-Language: de-DE,de;q=0.5
Connection: keep-alive
Cache-Control: max-age=0
Response header:
Content-Type: application/json
Date: Mon, 31 July 2023 14:58:12 GMT
Server: Apache/2.4.7 (Ubuntu)
Cache-Control: no-cache