GET

HTTP-menetelmä

HTTP-menetelmän GET määrittely

GET-menetelmä pyytää kohderesurssin nykyisen valitun esityksen siirtoa. GET on tiedonhaun ensisijainen mekanismi ja lähes kaikkien suorituskykyoptimointien kohteena. Näin ollen kun puhutaan jonkin tunnistettavan tiedon hakemisesta HTTP:n kautta, tarkoitetaan yleensä GET-pyynnön tekemistä.

On houkuttelevaa ajatella, että resurssitunnisteet ovat etätiedostojärjestelmän polunnimiä ja esitykset ovat kopioita näiden tiedostojen sisällöstä. Itse asiassa monet resurssit on toteutettu juuri näin (katso kohta 9.1 asiaan liittyvistä turvallisuusnäkökohdista). Käytännössä tällaisia rajoituksia ei kuitenkaan ole. Resurssin HTTP-rajapinta voidaan yhtä hyvin toteuttaa sisältöobjektien puuna, ohjelmallisena näkymänä erilaisiin tietokantatietueisiin tai porttina muihin tietojärjestelmiin. Jopa silloin, kun URI-kartoitusmekanismi on sidottu tiedostojärjestelmään, alkuperäispalvelin saatetaan konfiguroida suorittamaan tiedostot pyynnön syötteenä ja lähettämään tulosteet esityksenä sen sijaan, että tiedostot siirrettäisiin suoraan. Siitä huolimatta vain alkuperäpalvelimen on tiedettävä, miten kukin sen resurssitunniste vastaa toteutusta ja miten kukin toteutus onnistuu valitsemaan ja lähettämään kohderesurssin nykyisen esityksen vastauksena GET:iin.

Asiakas voi muuttaa GET:n semantiikkaa "alueeksi", jolloin se pyytää vain jonkin osan tai joidenkin osien siirtoa valitusta esityksestä, lähettämällä pyynnön Range-otsikkokentän (RFC7233).

GET-pyyntösanomassa olevalla hyötykuormalla ei ole määriteltyä semantiikkaa; hyötykuormarungon lähettäminen GET-pyynnössä saattaa johtaa siihen, että jotkin nykyiset toteutukset hylkäävät pyynnön.

GET-pyynnön vastaus on välimuistissa; välimuisti VOI käyttää sitä seuraavien GET- ja HEAD-pyyntöjen täyttämiseen, ellei Cache-Control-otsakekenttä toisin ilmoita (RFC7234:n 5.2 jakso).

IETF (Internet Engineering Task Force) ja W3C (World Wide Web Consortium) ovat määritelleet HTTP-menetelmän GET asiakirjan RFC 7231 kohdassa 4.3.1.

Menetelmän GET kuvaus

HTTP-protokollan GET-metodia voidaan verrata digitaaliseen kirjastonhoitajaan. Se pyytää kohteliaasti palvelinta näyttämään tietoja tekemättä muutoksia itse tietoihin – se on puhtaasti passiivinen pyyntö.

Mikä tekee GET-metodista erityisen?

  1. Johdonmukaisuus: Kuvittele pyytäväsi kirjastonhoitajalta samaa kirjaa useita kertoja – saisit saman kirjan joka kerta. Sama pätee GET-pyyntöön: se tuottaa johdonmukaisesti saman tuloksen.
  2. Lue, älä kirjoita: GET-pyynnöllä on tarkkailijan luonne. Se tarkastelee tietoja mutta ei muuta niitä.
  3. Tiedot URL-osoitteessa: Ajattele URL-osoitetta osoitteena tai hakukorttina. Se kertoo, mitä kirjaa tai tietoa etsit. Kuitenkin varoitus: näillä korteilla ei saisi olla yksityisiä muistiinpanoja, sillä muut voivat nähdä ne.
  4. Nopeat ja tehokkaat vastaukset: Vastausten välimuistin ansiosta GET-metodi voi nopeasti vastata toistuviin pyyntöihin, aivan kuten hyvin järjestäytynyt kirjastonhoitaja, joka tietää tarkalleen, missä kukin kirja sijaitsee.

Mutta sillä on myös rajoituksia:

  1. Rajoitettu tila muistiinpanoille: URL-osoitteessa on vain rajallisesti tilaa tiedolle. Se on kuin kirjoittaminen pieneen hakukorttiin.
  2. Ei salaisuuksia: Koska URL-osoitteet ovat näkyvissä ja ne voidaan tallentaa, et saisi merkitä niihin mitään arkaluontoista tietoa.
  3. Ei sekaantumista: Tarkkailija ei vaikuta siihen, mitä hän tarkkailee. Siksi GET-metodia ei tulisi käyttää tietojen muokkaamiseen. Tätä varten on muita työkaluja digitaalisessa työkalupakissamme.

Kaiken kaikkiaan GET-metodi on luotettava ja olennainen työkalu digitaalisessa tilassa, auttaen meitä noutamaan tietoa tehokkaasti ja turvallisesti.

Esimerkki HTTP-menetelmästä 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