GET

HTTP метод

Спецификация на HTTP метод GET

Методът GET изисква прехвърляне на текущо избрано представяне за целевия ресурс. GET е основният механизъм за извличане на информация и е във фокуса на почти всички оптимизации на производителността. Следователно, когато се говори за извличане на някаква идентифицируема информация чрез HTTP, обикновено се има предвид извършването на заявка GET.

Изкушаващо е да се мисли за идентификаторите на ресурсите като за имена на пътища към отдалечени файлови системи, а за представянията - като за копие на съдържанието на такива файлове. Всъщност така са реализирани много ресурси (вж. раздел 9.1 за свързаните с това съображения за сигурност). На практика обаче няма такива ограничения. HTTP интерфейсът за даден ресурс е също толкова вероятно да бъде реализиран като дърво от обекти на съдържанието, програмен изглед на различни записи в базата данни или портал към други информационни системи. Дори когато механизмът за съпоставяне на URI е свързан с файлова система, сървърът на произхода може да бъде конфигуриран да изпълнява файловете със заявката като вход и да изпраща изхода като представяне, а не да прехвърля файловете директно. Независимо от това, само сървърът на произхода трябва да знае как всеки от неговите идентификатори на ресурси съответства на изпълнение и как всяко изпълнение успява да избере и изпрати текущо представяне на целевия ресурс в отговор на GET.

Клиентът може да промени семантиката на GET, за да бъде "заявка за обхват", като поиска прехвърляне само на някои части от избраното представяне, чрез изпращане на заглавно поле Range в заявката ([RFC7233]).

Потребният товар в съобщението за заявка GET няма определена семантика; изпращането на тяло на полезен товар в заявка GET може да доведе до отхвърляне на заявката от някои съществуващи реализации.

Отговорът на заявка GET може да се кешира; кешът МОЖЕ да го използва за удовлетворяване на последващи заявки GET и HEAD, освен ако не е посочено друго от заглавното поле Cache-Control (раздел 5.2 на [RFC7234]).

HTTP метод GET е специфициран в раздел 4.3.1 на документ RFC 7231 от Internet Engineering Task Force (IETF) и World Wide Web Consortium (W3C).

Описание на метода GET

Методът GET на HTTP протокола може да се сравни с дигитален библиотекар. Той учтиво моли сървъра да представи данни без да прави промени в самите данни – изцяло пасивна заявка.

Какво прави метода GET специален?

  1. Последователност: Представете си да питате библиотекаря за същата книга няколко пъти – всеки път бихте получили същата книга. Същото важи и за заявката GET: тя последователно доставя същия резултат.
  2. Четене, не писане: Заявката GET има характер на наблюдател. Тя гледа данните, но не ги променя.
  3. Информация в URL: Мислете за URL като за адрес или индексна карта. Той указва коя книга или информация търсите. Обаче, внимание: тези карти не трябва да съдържат лични бележки, тъй като те могат да бъдат видяни от други.
  4. Бързи и ефективни отговори: Благодарение на възможността за кеширане на отговорите, методът GET може бързо да отговаря на повторни заявки, точно като добре организиран библиотекар, който знае точно къде се намира всяка книга.

Но има и ограничения:

  1. Ограничено място за бележки: URL има само толкова място за информация. Това е като писане на малка индексна карта.
  2. Без тайни: Тъй като URL-ите са видими и могат да бъдат съхранявани, не трябва да записвате никаква чувствителна информация в тях.
  3. Без намеса: Наблюдателят не влияе на това, което наблюдава. Затова методът GET не трябва да се използва за промяна на данни. Има други инструменти в нашия дигитален куфар за това.

Общо взето, методът GET е надежден и съществен инструмент в дигиталното пространство, който ни помага да извличаме информация ефективно и безопасно.

Пример за HTTP метод 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