W formularzach HTML najczęściej spotkasz dwie metody wysyłania danych: GET i POST. Różnią się one przede wszystkim tym, gdzie trafiają dane i jakie ma to skutki praktyczne.
POST przesyła dane w treści żądania HTTP (tzw. body). Z tego powodu dane nie są dopisywane do adresu URL jako parametry zapytania, więc użytkownik zwykle nie widzi ich w pasku adresu. To ogranicza ryzyko przypadkowego ujawnienia danych przez kopiowanie linku, zapis w historii jako parametrów czy przekazanie w referrerze.
Stwierdzenie, że POST jest "wskazana przy danych poufnych" oddaje typową praktykę projektową: logowanie, rejestracja czy formularze z danymi osobowymi zwykle realizuje się przez POST. Trzeba jednak pamiętać o kluczowej zasadzie: sama metoda POST nie szyfruje danych. Poufność transmisji zapewnia dopiero użycie HTTPS (szyfrowane połączenie), niezależnie od tego, czy używasz GET, czy POST.
Dlaczego pozostałe opisy nie pasują do POST?
- Opis "Dane przesyłane są za pomocą adresu URL…" odnosi się do GET, bo w GET parametry są częścią URL (po znaku ?).
- Opis z limitem długości adresu także dotyczy URL (a więc w praktyce zapytań GET). Limity długości nie są definiowane jako jedna stała wartość w HTTP; zależą od przeglądarki i serwera, ale problem jest typowy właśnie dla długich URL.
- Opis "Może być zapisana jako zakładka…" pasuje do GET, bo stan zapytania jest w URL, który da się zapisać jako zakładkę i odtworzyć. Przy POST odtworzenie identycznego żądania z zakładki nie jest standardowym mechanizmem.
Wskazówka egzaminacyjna: jeśli w odpowiedzi pojawia się "widoczne w URL", "zakładka", "historia z parametrami", myśl o GET. Jeśli mowa o "body", "większe dane", "dane wrażliwe (w praktyce)", myśl o POST — pamiętając o roli HTTPS w bezpieczeństwie.
