Jakie są główne różnice między metodami żądania HTTP GET i POST?

Cel

• GET żąda reprezentacji zasobu. Według specyfikacji jest to tylko do odczytu: klient nie oczekuje żadnej zmiany stanu serwera. RFC 9110 zauważa, że ​​wysyłanie treści w żądaniu GET ma niezdefiniowaną semantykę, więc GET nie powinien przenosić treści.
• POST prosi zasób docelowy o przetworzenie danych zawartych w treści żądania zgodnie z semantyką tego zasobu (utwórz rekord, prześlij formularz, prześlij plik itp.).

Gdzie trafiają dane

• GET przenosi parametry w ciągu zapytania URL (po ?, sformatowanym jako key=value&...). Są one widoczne w pasku adresu i zapisywane w historii przeglądarki oraz logach serwera i są ograniczone praktycznym limitem długości adresu URL.
• POST przenosi dane w treści żądania; typ jest podany w nagłówku Content-Type. Formularze HTML zazwyczaj używają application/x-www-form-urlencoded (domyślnie) lub multipart/form-data (dla plików). Nie ma stałego limitu rozmiaru na poziomie protokołu, ale serwery i serwery proxy konfigurują własne wartości maksymalne (np. Nginx client_max_body_size).

Właściwości zgodnie z RFC 9110

• Bezpieczny: GET jest bezpieczny (tylko do odczytu); POST nie.
• Idempotentny: żądanie jest idempotentne, jeśli wykonanie go N razy ma taki sam wpływ na stan serwera, jak jego jednorazowe wykonanie. GET jest idempotentny; POST nie jest — powtarzanie go może spowodować utworzenie duplikatów, na przykład dwóch identycznych zamówień. Idempotentny to nie to samo, co bezpieczny (PUT i DELETE są idempotentne, ale nie bezpieczne) i nie mówi nic o identyczności treści odpowiedzi.
• Możliwość buforowania: odpowiedzi GET są domyślnie buforowane; Odpowiedzi POST można buforować tylko wtedy, gdy zawierają wyraźną informację o aktualności i pasujący nagłówek Content-Location, co jest rzadkością w praktyce.

Implikacje praktyczne

• Użyj GET do wyszukiwania i nawigacji; wyniki można bezpiecznie powtarzać, dodawać do zakładek i pobierać wstępnie, a odświeżanie strony GET jest nieszkodliwe.
• Użyj POST do działań zmieniających stan i do wysyłania wrażliwych lub dużych ładunków. Odświeżenie lub powrót do strony POST powoduje wyświetlenie w przeglądarce ostrzeżenia „potwierdź ponowne przesłanie formularza”.
• Nigdy nie wysyłaj haseł za pomocą metody GET — wylądują w adresie URL, dziennikach i historii. To jest higiena, a nie szyfrowanie: HTTPS szyfruje zarówno adres URL, jak i treść podczas przesyłania, ale adres URL jest nadal rejestrowany.

Typowe działania następcze

• Bezpieczne metody to GET, HEAD, OPTIONS; Metody idempotentne to GET, HEAD, PUT, DELETE; POST też nie.
• Obie metody są obsługiwane przez formularze HTML (atrybut method).
• „Bezpieczny” w rozumieniu RFC oznacza brak zmiany stanu, a nie ochronę danych.
• Idempotencja POST na poziomie aplikacji jest często wymuszana przy użyciu kluczy idempotencji.