Web

Metody HTTP

GET, POST, PUT, DELETE i inne metody żądań HTTP oraz ich zastosowanie.

Czym są metody HTTP? Operacje na zasobach

Protokół Transferu Hipertekstu (HTTP) to protokół warstwy aplikacji używany przez przeglądarki internetowe (klientów) i serwery WWW do wymiany komunikatów. W jego skład wchodzą między innymi . Nazwy metod są tokenami rozróżnianymi wielkością liter i są rejestrowane przez IANA. Wskazują one serwerowi, co klient chce zrobić z określonym zasobem, takim jak strona internetowa, obraz, wideo lub dane z bazy danych.

Kiedy przeglądarka wysyła żądanie do serwera, metoda jest jednym z jego pierwszych elementów i określa semantykę operacji. Prośba o dostarczenie strony internetowej ma inny cel niż zapisanie nowego zdjęcia profilowego użytkownika. Rozdzielenie operacji na metody ułatwia serwerom i interfejsom API spójne stosowanie semantyki HTTP. Popularne metody poniżej porównano według celu i właściwości.

Podstawowe metody HTTP

Istnieje wiele metod HTTP, lecz kilka z nich obsługuje większość typowych interakcji w internecie. Ich właściwości pomagają zrozumieć działanie usług webowych.

Metodę interpretuje się razem z docelowym URI, polami żądania, treścią i semantyką zasobu, które wpływają na odpowiedź oraz kod statusu.

GET

Metoda GETGET służy do żądania reprezentacji określonego zasobu. Jest powszechnie używana w sieci. Wpisanie adresu URL w przeglądarce, kliknięcie hiperłącza oraz ładowanie obrazów i arkuszy stylów powodują wysłanie żądań GETGET. Celem żądania GETGET jest pobranie danych z serwera.

Właściwości GET

  • Bezpieczna: Żądania GETGET są uważane za . Złożenie żądania GETGET nie oznacza żądania zmiany danych, utworzenia nowego zasobu ani innego działania modyfikującego zasób. Wyszukiwarka może przeszukiwać sieć i wysyłać wiele żądań GETGET, ponieważ ich semantyka nie przewiduje modyfikacji indeksowanych stron.
  • Idempotentna: Żądania GETGET są . Wielokrotne wysłanie tego samego żądania GETGET powinno mieć taki sam skutek. Pięciokrotne zażądanie strony głównej portalu informacyjnego zwróci za każdym razem tę samą stronę (pomijając dynamiczne aktualizacje treści), a kolejne żądania będą miały taki sam zamierzony wpływ na stan serwera.
  • Dane w URL: Żądanie GETGET często umieszcza parametry wyszukiwania w adresie URL, na przykład /szukaj?q=http. Wartości w URI mogą trafić do logów serwera, historii przeglądarki i narzędzi monitorujących. Treść żądania GETGET ma w HTTP nieokreśloną ogólnie semantykę, dlatego klient nie powinien jej wysyłać bez uzgodnienia z serwerem. Przy danych poufnych można rozważyć treść POSTPOST. Sama zmiana miejsca przekazania danych nie zapewnia poufności.
  • Możliwość buforowania (Cacheable): Odpowiedzi na GETGET mogą być przechowywane przez przeglądarki, serwery proxy i sieci CDN (Content Delivery Networks), jeśli pozwalają na to reguły cache. Kolejne żądania tego samego zasobu mogą wtedy korzystać z pamięci podręcznej zamiast z połączenia z serwerem źródłowym.

Przykładowy scenariusz

Przeglądarka żąda strony profilowej użytkownika.

Żądanie
GET /uzytkownicy/profil/123 HTTP/1.1
Host: api.example.com
Accept: application/json
Odpowiedź
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 104

{
"userId": 123,
"username": "JanKowalski",
"email": "jan.kowalski@example.com"
}

POST

Metoda POSTPOST służy do przesłania jednostki do określonego zasobu, co często powoduje zmianę stanu lub skutki uboczne na serwerze. Najczęściej jest używana do tworzenia nowego zasobu podrzędnego wobec innego zasobu. Na przykład przesłanie komentarza do wpisu na blogu tworzy nowy zasób komentarza w ramach tego konkretnego wpisu.

Właściwości POST

  • Niebezpieczna: POSTPOST nie jest metodą bezpieczną. Może zlecić zasobowi utworzenie lub modyfikację danych, zależnie od semantyki tego zasobu. Przesłanie formularza rejestracyjnego może zmienić bazę danych serwera.
  • Nieidempotentna w definicji metody: Specyfikacja nie klasyfikuje POSTPOST jako idempotentnej. Powtórzenie tego samego żądania może utworzyć wiele zasobów. Dwukrotne wysłanie formularza zamówienia może więc utworzyć dwa zamówienia, choć konkretna usługa może stosować własne mechanizmy wykrywania powtórzeń.
  • Dane w ciele (Body): Dane przesyłane w żądaniu POSTPOST umieszcza się w treści komunikatu, więc nie są częścią URI. Treść nie zapewnia szyfrowania ani poufności, lecz umożliwia przesyłanie dużych ilości danych, w tym plików.
  • Ograniczona możliwość buforowania: Odpowiedź na POSTPOST może być użyta z pamięci podręcznej tylko przy jawnej świeżości, na przykład przez Cache-Control lub Expires, oraz z polem Content-Location równym URI żądania.

Przykładowy scenariusz

Użytkownik zakłada nowe konto.

Żądanie
POST /uzytkownicy HTTP/1.1
Host: api.example.com
Content-Type: application/json
Content-Length: 56

{
"username": "AnnaNowak",
"password": "supersecret"
}
Odpowiedź
HTTP/1.1 201 Created
Location: /uzytkownicy/456

{
"userId": 456,
"message": "Użytkownik utworzony pomyślnie"
}

PUT

Metoda PUTPUT służy do zastąpienia całej reprezentacji docelowego zasobu ładunkiem żądania. Jeśli zasób docelowy nie istnieje, serwer może go utworzyć. Różnica w stosunku do POSTPOST polega na tym, że PUTPUT jest kierowane na konkretny, znany adres URL, podczas gdy POSTPOST wysyła dane na adres URL, który je przetwarza (np. /uzytkownicy), a serwer decyduje o adresie URL nowego zasobu.

Właściwości PUT

  • Niebezpieczna: Podobnie jak POSTPOST, PUTPUT modyfikuje stan na serwerze.
  • Idempotentna: To jest cecha definiująca PUTPUT. Wielokrotne wysłanie tego samego żądania PUTPUTbędzie miało dokładnie taki sam skutek, jak wysłanie go raz. Jeśli wyślesz żądanie aktualizacji imienia użytkownika na "Janina Kowalska", pierwsze żądanie je zmieni. Drugie, trzecie i czwarte żądanie po prostu ponownie ustawią imię na "Janina Kowalska", co daje ten sam stan końcowy na serwerze.
  • Dane w ciele (Body): Ładunek, który reprezentuje kompletnie zaktualizowany zasób, jest przesyłany w ciele wiadomości.

Przykładowy scenariusz

Aktualizacja adresu email użytkownika.

Żądanie
PUT /uzytkownicy/123 HTTP/1.1
Host: api.example.com
Content-Type: application/json

{
"username": "JanKowalski",
"email": "jan.nowy.email@example.com"
}
Odpowiedź
HTTP/1.1 200 OK

{
"userId": 123,
"username": "JanKowalski",
"email": "jan.nowy.email@example.com"
}

DELETE

Metoda DELETEDELETE żąda usunięcia powiązania zasobu docelowego z jego bieżącą funkcją na serwerze. Reprezentacja lub dane mogą zostać usunięte, zarchiwizowane albo zachowane zależnie od implementacji.

Właściwości DELETE

  • Niebezpieczna: Zmienia stan zasobu docelowego i jego mapowanie po stronie serwera.
  • Idempotentna: DELETEDELETE jest idempotentne. Pierwsze żądanie usunięcia /uzytkownicy/123 usunie użytkownika. Drugie żądanie usunięcia tego samego zasobu doprowadzi do tego samego stanu. Użytkownik o ID 123 nie istnieje. Serwer może odpowiedzieć 204NoContent204 No Content za pierwszym razem i 404NotFound404 Not Found za drugim, ale stan końcowy samego zasobu jest identyczny (już go nie ma).

Przykładowy scenariusz

Usuwanie konta użytkownika.

Żądanie
DELETE /uzytkownicy/123 HTTP/1.1
Host: api.example.com
Odpowiedź
HTTP/1.1 204 No Content

HEAD

Metoda HEADHEAD prosi o odpowiedź z polami nagłówkowymi takimi jak dla GETGET, bez treści odpowiedzi. Serwer może pominąć pola wyznaczane dopiero podczas generowania treści. Metoda służy do sprawdzania metadanych zasobu, takich jak Content-Type, Content-Length czy Last-Modified, bez pobierania całego pliku.

Właściwości HEAD

  • Bezpieczna: Tak, nie zmienia stanu serwera.
  • Idempotentna: Tak, z tych samych powodów co GETGET.

Przykładowy scenariusz

Sprawdzenie rozmiaru dużego pliku przed podjęciem decyzji o jego pobraniu.

Żądanie
HEAD /pobieranie/duzy-plik.zip HTTP/1.1
Host: storage.example.com
Odpowiedź
HTTP/1.1 200 OK
Content-Type: application/zip
Content-Length: 104857600
Last-Modified: Fri, 15 Jun 2025 10:00:00 GMT

Metody dodatkowe: narzędzia specjalistyczne

Poza metodami podstawowymi, HTTP definiuje kilka innych o bardziej wyspecjalizowanych celach, często używanych w tworzeniu API lub do diagnostyki sieci.

OPTIONS
Metoda OPTIONSOPTIONS służy do opisywania opcji komunikacji dla zasobu docelowego. Klient może użyć OPTIONSOPTIONS, aby dowiedzieć się, które metody HTTP serwer obsługuje dla określonego adresu URL. Mechanizm (Cross-Origin Resource Sharing) wykorzystuje takie żądanie do sprawdzenia uprawnień. Zanim przeglądarka wyśle złożone żądanie do innej domeny (np. PUTPUT lub DELETEDELETE), najpierw wysyła żądanie OPTIONSOPTIONS (tzw. żądanie pre-flight), aby zapytać serwer o pozwolenie.
PATCH
Metoda PATCHPATCH służy do stosowania częściowych modyfikacji zasobu. Podczas gdy PUTPUT zastępuje cały zasób, PATCHPATCH dostarcza zestaw instrukcji, jak go zmienić. Na przykład, żądanie PATCHPATCH może zawierać tylko instrukcję zmiany adresu e-mail użytkownika, pozostawiając nazwę użytkownika i inne pola nietknięte. Może to być bardziej wydajne niż przesyłanie całej reprezentacji zasobu. PATCHPATCHnie jest bezpieczne i, co ważne, niekoniecznie jest idempotentne. Na przykład, instrukcja patch "dodaj 10 do wyniku użytkownika" dałaby inny wynik, gdyby została wysłana dwukrotnie.
CONNECT
Metoda CONNECTCONNECT ustanawia tunel do serwera zidentyfikowanego przez zasób docelowy. W typowym użyciu służy do zestawienia połączenia HTTPSHTTPS przez proxy HTTPHTTP. Proxy może wtedy zestawić połączenie z hostem docelowym i przekazywać bajty w obu kierunkach. Treść HTTPS pozostaje dla niego nieczytelna bez terminacji TLS.
TRACE
Metoda TRACETRACE wykonuje test pętli zwrotnej wiadomości wzdłuż ścieżki do zasobu docelowego. Pozwala klientowi zobaczyć, jakie (jeśli w ogóle) zmiany lub dodatki zostały wprowadzone przez serwery pośredniczące (np. proxy) do komunikatu żądania. Jest to narzędzie do debugowania i diagnostyki. Ze względu na potencjalne ryzyka bezpieczeństwa (Cross-Site Tracing), jest często wyłączana na produkcyjnych serwerach internetowych.

Bezpieczeństwo a idempotencja metod HTTP

Bezpieczeństwo i idempotencja opisują różne cechy. Bezpieczeństwo dotyczy żądanej operacji, a idempotencja jej zamierzonego skutku przy powtórzeniu żądania.

Bezpieczeństwo (Safety)

Metoda jest bezpieczna, jeśli jej semantyka zakłada operację odczytową. Klient nie żąda zmiany stanu zasobu. Logi, statystyki i inne działania implementacji mogą się zmieniać po stronie serwera, lecz nie wynikają z żądanej semantyki.

Metody bezpieczne: GETGET, HEADHEAD, OPTIONSOPTIONS, TRACETRACE

Metody niebezpieczne: POSTPOST, PUTPUT, DELETEDELETE, PATCHPATCH

Idempotencja (Idempotency)

Metoda jest idempotentna, jeśli wielokrotne wysłanie identycznego żądania ma taki sam zamierzony wpływ na serwer, jak wysłanie go raz. Stan zasobu po pierwszym i kolejnym żądaniu powinien być taki sam, choć odpowiedzi mogą się różnić. Przykładowo wielokrotne ustawienie parametru głośności na 15 pozostawia go na poziomie 15.

Metody idempotentne: GETGET, HEADHEAD, PUTPUT, DELETEDELETE, OPTIONSOPTIONS, TRACETRACE

Metody nieidempotentne: POSTPOST, PATCHPATCH (generalnie)

Różnica: Bezpieczeństwo opisuje zamiar odczytu operacji. Idempotencja opisuje ten sam stan docelowy po wielokrotnym wykonaniu. Wszystkie metody bezpieczne są z definicji również idempotentne. PUTPUT i DELETEDELETE są idempotentne, ponieważ prowadzą do określonego stanu, lecz pozostają niebezpieczne, gdyż ten stan zmieniają.

Powiązane artykuły