Metody HTTP: GET, POST, PUT, PATCH i DELETE w testach API

Czas czytania: około 16 minut

Aplikacja pokazuje komunikat „zapisano”, a w bazie nic się nie zmieniło. Formularz wygląda na sprawny, przycisk reaguje, użytkownik dostaje zielony pasek. Dopiero rzut oka na żądanie ujawnia, że frontend wysłał GET z danymi w adresie, a serwer grzecznie odpowiedział 200 i nic nie zrobił. Takie błędy nie wynikają z braku testów, tylko z tego, że nikt nie sprawdził, jaką metodą HTTP aplikacja rozmawia z backendem i czy backend rozumie tę rozmowę tak samo.

Metody HTTP to słownik tej rozmowy. Jest ich dziewięć, w codziennej pracy testera liczy się pięć, a różnica między PUT i PATCH potrafi decydować o tym, czy klient traci dane. W tym artykule przechodzimy przez wszystkie metody z przykładami żądań, kodami odpowiedzi, regułami bezpieczeństwa i idempotentności oraz listą kontrolną do testów każdej z nich.

Co to są metody HTTP?

Metoda HTTP to pierwsze słowo każdego żądania, które przeglądarka, aplikacja mobilna albo skrypt testowy wysyła do serwera. Stoi przed adresem zasobu i mówi, jaką operację klient chce wykonać. Żądanie GET /uzytkownicy/42 prosi o dane użytkownika numer 42, żądanie DELETE /uzytkownicy/42 prosi o jego usunięcie, a różnica między nimi to jedno słowo, które serwer musi zinterpretować poprawnie.

Standard opisujący znaczenie metod to RFC 9110, dokument organizacji IETF z czerwca 2022 roku, który zastąpił wcześniejsze RFC 7231. Definiuje osiem metod: GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS i TRACE. Dziewiąta, PATCH, ma osobny dokument RFC 5789 z 2010 roku. Standard nie mówi serwerowi, co dokładnie ma zrobić z zasobem, tylko jakie są oczekiwania wobec danej metody: czy może zmieniać stan, czy jej powtórzenie jest bezpieczne, czy odpowiedź wolno zapisać w pamięci podręcznej.

Dla testera to rozróżnienie ma praktyczny sens. Jeśli aplikacja używa GET do usuwania rekordów, to każdy robot indeksujący, każde odświeżenie karty i każde podpowiadanie adresu w przeglądarce może skasować dane. Jeśli POST tworzy zamówienie, a użytkownik kliknie dwa razy, powstaną dwa zamówienia. W projekcie dla Argos, sklepu internetowego, przeniesienie sprawdzeń z interfejsu na poziom żądań HTTP skróciło regresję z 5 dni do 10 godzin, a liczba błędów krytycznych na produkcji spadła o 46 procent według danych klienta. Metody HTTP to nie ciekawostka z dokumentacji, tylko zestaw obietnic, których złamanie widać na produkcji. Jak sprawdzać te obietnice narzędziem, opisujemy w artykule o tym, czym jest Postman i jak wysłać w nim pierwsze żądanie.

Lista metod HTTP w jednej tabeli

Dziewięć metod, trzy cechy i typowe kody odpowiedzi, wszystko w jednym miejscu. Kolumna „bezpieczna” oznacza, że metoda nie powinna zmieniać stanu serwera. Kolumna „idempotentna” oznacza, że wysłanie tego samego żądania kilka razy daje ten sam skutek co wysłanie raz. Obie cechy wracają w dalszej części artykułu, bo od nich zależy, jak projektować testy powtórzeń.

Nie każde API respektuje ten podział. Zdarzają się serwisy, w których POST służy do wszystkiego, a PUT nie istnieje. Tabela opisuje, jak powinno być według standardu, a zadaniem testów jest sprawdzić, jak jest naprawdę i czy odstępstwa są świadome.

GET: pobieranie danych bez skutków ubocznych

GET to najczęściej używana metoda w sieci i jedyna, którą przeglądarka wysyła po wpisaniu adresu. Prosi o reprezentację zasobu i nie powinna niczego zmieniać po stronie serwera. Parametry idą w adresie, po znaku zapytania, na przykład GET /produkty?kategoria=szkolenia&strona=2. Standard mówi wprost, że ciało żądania GET nie ma zdefiniowanego znaczenia, więc serwery mogą je zignorować albo odrzucić.

W testach GET sprawdzacie trzy rzeczy. Po pierwsze, czy odpowiedź ma właściwy kod i kształt danych, w tym pola obowiązkowe i typy wartości. Po drugie, czy adres z parametrami spoza zakresu zwraca 400 albo pustą listę, a nie 500. Po trzecie, czy w adresie nie ma danych wrażliwych, bo adresy zapisują się w logach serwera, w historii przeglądarki i w nagłówku Referer, gdy użytkownik przejdzie na inną stronę. Token sesji w parametrze GET to klasyczny błąd, który wychodzi dopiero przy audycie bezpieczeństwa.

Osobny temat to pamięć podręczna. Odpowiedzi na GET są domyślnie buforowalne, więc test, który sprawdza, czy po zmianie danych klient widzi nową wartość, musi uwzględniać nagłówki Cache-Control i ETag. Kod 304 Not Modified w odpowiedzi na GET nie jest błędem, tylko informacją, że klient ma aktualną kopię.

POST: tworzenie zasobu i wszystko, co nie pasuje gdzie indziej

POST wysyła dane w ciele żądania i prosi serwer o ich przetworzenie według logiki danego adresu. Najczęściej oznacza to utworzenie nowego zasobu: POST /zamowienia z danymi zamówienia w formacie JSON powinno zwrócić 201 Created oraz nagłówek Location z adresem nowego zasobu. Standard dopuszcza jednak także inne zastosowania: uruchomienie operacji, przesłanie formularza, dopisanie wpisu do listy. POST to metoda „wszystko inne”, i właśnie dlatego jest najtrudniejsza do testowania.

POST nie jest idempotentny. Dwa identyczne żądania tworzą dwa zasoby, i to jest zachowanie poprawne, nie błąd. Problem zaczyna się wtedy, gdy klient ponawia żądanie po błędzie sieci albo użytkownik klika przycisk dwa razy. Dobrze zaprojektowane API obsługuje to kluczem idempotentności w nagłówku, na przykład Idempotency-Key, dzięki któremu serwer rozpoznaje powtórkę i zwraca wynik pierwszego żądania zamiast tworzyć duplikat. W testach warto sprawdzić, czy taki mechanizm istnieje, a jeśli nie, opisać ryzyko podwójnych zamówień jako defekt projektowy.

Walidacja danych wejściowych to drugi filar testów POST. Puste ciało, brak pola obowiązkowego, zły typ wartości, za długi tekst, niedozwolone znaki, format inny niż JSON: każdy z tych przypadków powinien kończyć się kodem z serii 4xx i czytelnym komunikatem, nie wyjątkiem z serwera. Jeśli na złe dane serwer odpowiada 500, walidacja nie działa, tylko aplikacja wywraca się, zanim do niej dojdzie.

PUT i PATCH: czym się różnią i dlaczego to ważne

PUT zastępuje zasób w całości, PATCH zmienia jego fragment, a mylenie ich prowadzi do utraty danych. Jeśli użytkownik ma imię, nazwisko i telefon, a klient wyśle PUT /uzytkownicy/42 tylko z nowym telefonem, poprawnie działający serwer nadpisze cały zasób i skasuje imię oraz nazwisko. To nie jest błąd serwera, tylko dokładnie to, o co klient poprosił. Ten sam telefon wysłany przez PATCH zmieni wyłącznie telefon.

Najciekawszy przypadek testowy dla obu metod to pole pominięte w żądaniu. Dla PUT poprawny wynik to wyczyszczenie pola, dla PATCH jego zachowanie. Druga rzecz to wartość null: w PATCH oznacza zwykle „wyczyść to pole”, co jest czymś innym niż pominięcie pola. Serwery, które nie rozróżniają tych dwóch sytuacji, kasują dane przy okazji najprostszej edycji profilu. Jak zamienić takie sprawdzenie w automatyczny test z asercją, pokazujemy w artykule o asercjach w testach automatycznych.

DELETE: usuwanie zasobu

DELETE prosi o usunięcie zasobu i jest idempotentny: drugie usunięcie tego samego zasobu nie zmienia już stanu serwera. Odpowiedź po udanym usunięciu to zazwyczaj 204 No Content bez ciała albo 200 z potwierdzeniem. Sporny jest kod przy powtórce: część API zwraca 404, bo zasobu już nie ma, część 204, bo skutek jest ten sam. Obie odpowiedzi są zgodne ze standardem, ale API powinno zachowywać się spójnie, i to jest rzecz do sprawdzenia.

DELETE to metoda, przy której autoryzacja ma największą wagę. Test, w którym użytkownik A próbuje usunąć zasób użytkownika B, powinien kończyć się kodem 403, a nie 204. Test bez tokenu powinien dać 401. Jeśli którykolwiek z tych scenariuszy przechodzi, aplikacja ma lukę, która kosztuje więcej niż wszystkie pozostałe defekty razem. Ile dokładnie kosztuje luka bezpieczeństwa, której nikt nie szukał, liczymy w osobnym artykule na Strefie QA.

Warto też sprawdzić, co dzieje się z zasobami powiązanymi. Usunięcie użytkownika może kasować jego zamówienia, może je osierocić, może być zablokowane kodem 409 Conflict, dopóki zamówienia istnieją. Każda z tych decyzji jest dopuszczalna, ale musi być zapisana w wymaganiach i sprawdzona testem, bo to właśnie tu API najczęściej zachowuje się inaczej, niż zakłada frontend.

HEAD, OPTIONS, TRACE i CONNECT: metody, które rzadko widać

Cztery pozostałe metody rzadko pojawiają się w kodzie aplikacji, ale każda ma zastosowanie w testach. HEAD działa jak GET, tylko bez ciała odpowiedzi: zwraca same nagłówki, w tym rozmiar zasobu i datę modyfikacji. Przydaje się do sprawdzenia, czy plik istnieje, bez pobierania go, na przykład przy testowaniu linków w tysiącach stron.

OPTIONS pyta serwer, jakie metody obsługuje dla danego adresu, i jest podstawą mechanizmu CORS w przeglądarkach. Gdy skrypt ze strony A wysyła żądanie do API na domenie B, przeglądarka najpierw wysyła OPTIONS jako żądanie wstępne i dopiero po zgodzie serwera puszcza właściwe żądanie. Błędy CORS, które widzicie w konsoli przeglądarki, to najczęściej źle obsłużony OPTIONS.

TRACE odbija otrzymane żądanie z powrotem do klienta i służy do diagnostyki po drodze przez serwery pośredniczące. Ze względów bezpieczeństwa większość serwerów produkcyjnych ma go wyłączonego, i to jest rzecz do sprawdzenia: TRACE na produkcji powinien zwracać 405 Method Not Allowed. CONNECT otwiera tunel przez serwer proxy, głównie dla ruchu szyfrowanego, i w testach API praktycznie się nie pojawia.

Bezpieczeństwo i idempotentność: dwie cechy, które decydują o testach

RFC 9110 dzieli metody na bezpieczne, idempotentne i pozostałe, a ten podział mówi testerowi, jakie scenariusze powtórzeń ma napisać. Metoda bezpieczna to taka, która nie powinna zmieniać stanu serwera: GET, HEAD, OPTIONS i TRACE. Metoda idempotentna to taka, której wielokrotne wysłanie daje ten sam skutek co jednokrotne: wszystkie bezpieczne plus PUT i DELETE. Każda bezpieczna metoda jest idempotentna, ale nie odwrotnie: PUT zmienia stan, tylko robi to za każdym razem tak samo.

Dlaczego to ma znaczenie poza dokumentacją? Bo klienci HTTP, biblioteki i serwery pośredniczące automatycznie ponawiają żądania idempotentne po błędzie sieci, a nie ponawiają POST. Jeśli Wasze API zmienia stan przez GET, robot indeksujący albo proxy może wywołać tę zmianę tysiąc razy. Jeśli PUT nie jest naprawdę idempotentny, na przykład dopisuje wpis do listy zamiast ją zastąpić, ponowienie po timeoucie zduplikuje dane. Test idempotentności to jeden z najtańszych testów API i jeden z najczęściej pomijanych. W naszej praktyce audytowej test powtórzenia zajmuje około 15 minut na punkt końcowy i wyłapuje defekty, których nie pokaże żaden test przez interfejs, bo interfejs nigdy nie wysyła tego samego żądania dwa razy. Jeśli Wasz zestaw testów nie ma takiego scenariusza, to jest pierwsza rzecz do dopisania.

Metody HTTP a kody odpowiedzi

Kod odpowiedzi mówi, jak serwer potraktował żądanie, i dla każdej metody istnieje zestaw kodów, które są poprawne, oraz takie, które sygnalizują błąd projektowy. Poniższa tabela zbiera kody, które najczęściej spotkacie w testach, razem z tym, co warto przy nich sprawdzić.

Dwie rzeczy z tej tabeli wracają w audytach najczęściej. Pierwsza to 405 bez nagłówka Allow: standard wymaga, żeby serwer podał listę dozwolonych metod, a większość frameworków robi to sama, więc jego brak oznacza zwykle ręcznie napisaną obsługę błędów. Druga to 200 z komunikatem błędu w ciele, czyli „operacja się nie udała, ale wszystko w porządku”. Takie odpowiedzi psują każde narzędzie monitorujące, bo dla niego 200 znaczy sukces.

Jak testować każdą metodę HTTP: lista kontrolna

Cztery karty poniżej to minimalny zestaw sprawdzeń dla każdej z głównych metod. Nie zastępują analizy wymagań, ale wyłapują większość defektów, które przechodzą przez testy klikane w interfejsie, bo interfejs pokazuje tylko szczęśliwą ścieżkę. Przejdźcie je dla każdego punktu końcowego w Waszym API, a przy okazji zobaczycie, ile z tych sprawdzeń Wasz obecny zestaw testów w ogóle wykonuje.

Do tego dochodzi jeden test wspólny dla wszystkich adresów: wysłanie każdej metody na każdy punkt końcowy i sprawdzenie, że niedozwolone kończą się 405. To dziesięć minut pracy w Postmanie albo jedna pętla w REST Assured, a wyłapuje adresy, które przez przypadek obsługują DELETE. Pełny warsztat takiego testowania, od pierwszego żądania po pipeline, opisujemy w artykule o testach API i testach integracyjnych w Postmanie.

Najczęstsze błędy w testach metod HTTP

Większość błędów w testach API nie polega na braku testu, tylko na sprawdzeniu niewłaściwej rzeczy. Pierwszy z nich to testowanie samego kodu odpowiedzi. Kod 200 mówi, że serwer nie zgłosił błędu, a nie że zrobił to, co trzeba. Po każdym żądaniu zmieniającym stan potrzebny jest GET, który potwierdzi zmianę, albo sprawdzenie w bazie.

Drugi błąd to pomijanie metod niedozwolonych. Zespół testuje GET i POST na adresie, bo tylko te dwie są w dokumentacji, a serwer po cichu obsługuje też DELETE, bo framework wygenerował go automatycznie. Trzeci to traktowanie PUT i PATCH jak jednej metody: w wielu zestawach testów istnieje jeden przypadek „edycja”, który nie sprawdza, co się dzieje z polami pominiętymi. Czwarty to brak testów powtórzeń, bo w interfejsie użytkownika nikt nie wysyła tego samego formularza dwa razy, a klient mobilny przy słabym zasięgu robi to regularnie.

Piąty błąd jest organizacyjny: kontrakt API istnieje tylko w głowie programisty. Gdy nie ma specyfikacji w formacie OpenAPI albo choćby tabeli metod i kodów, testy sprawdzają to, co akurat zwraca serwer, a nie to, co powinien zwracać. Zespół Quality Island napisał ponad 450 000 testów automatycznych, w dużej części na poziomie API, i z naszego doświadczenia wynika, że największa część ich wartości bierze się z kontraktu spisanego przed pierwszym testem, nie z liczby przypadków. Wtedy każda zmiana w backendzie jest jednocześnie zmianą wymagań i nikt nie wie, czy to defekt. Od czego zacząć porządkowanie takiego stanu, opisujemy w przewodniku po testowaniu API dla początkujących.

Najczęstsze pytania o metody HTTP

Ile jest metod HTTP?

Dziewięć: osiem zdefiniowanych w RFC 9110 (GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE) i PATCH z RFC 5789. W codziennej pracy z API używa się pięciu: GET, POST, PUT, PATCH i DELETE.

Czym różni się PUT od PATCH?

PUT zastępuje cały zasób tym, co jest w żądaniu, więc pola pominięte znikają. PATCH zmienia tylko pola przesłane w żądaniu, a resztę zostawia bez zmian. PUT jest idempotentny z definicji, PATCH nie musi być.

Czy GET może mieć ciało żądania?

Standard mówi, że ciało w GET nie ma zdefiniowanego znaczenia i może zostać odrzucone przez serwer albo serwer pośredniczący. Jeśli API wymaga ciała do pobrania danych, powinno używać POST, i tak robi na przykład większość interfejsów wyszukiwania ze złożonymi filtrami.

Co to znaczy, że metoda jest idempotentna?

Że wysłanie tego samego żądania wiele razy daje ten sam skutek co wysłanie raz. GET, HEAD, OPTIONS, TRACE, PUT i DELETE są idempotentne. POST nie jest: dwa identyczne POST tworzą zwykle dwa zasoby.

Jaki kod powinien zwrócić DELETE nieistniejącego zasobu?

Standard dopuszcza zarówno 404 (zasobu nie ma), jak i 204 (skutek osiągnięty). Ważne, żeby API zachowywało się spójnie i żeby ta decyzja była zapisana w kontrakcie.

Czym się różni 401 od 403?

401 oznacza, że serwer nie wie, kim jesteście: brak tokenu albo token nieważny. 403 oznacza, że wie, ale nie pozwala: jesteście zalogowani, tylko ten zasób nie jest Wasz. W testach oba kody sprawdza się osobnymi scenariuszami.

Powiązane na blogu Quality Island

• Postman: co to jest, do czego służy i jak zacząć testować API
• Postman: testy API i testy integracyjne w praktyce QA
• Testowanie API dla początkujących
• Testy integracyjne: co to jest, rodzaje, przykłady i jak je wykonywać krok po kroku
• Asercja: co to jest i jak używać asercji w testach automatycznych
• Narzędzia do testowania oprogramowania: przegląd najlepszych rozwiązań

Pełna lista źródeł

• IETF, RFC 9110: HTTP Semantics, czerwiec 2022, w tym sekcje o metodach, metodach bezpiecznych i idempotentnych oraz kodach odpowiedzi
• IETF, RFC 5789: PATCH Method for HTTP, marzec 2010
• MDN Web Docs, HTTP request methods oraz HTTP response status codes, stan dokumentacji na wrzesień 2026
• MDN Web Docs, Cross-Origin Resource Sharing (CORS), o żądaniach wstępnych OPTIONS, stan na wrzesień 2026
• Postman, Request basics, wybór metody i budowa żądania, dokumentacja aktualna na wrzesień 2026
• Dane własne Quality Island z projektu dla Argos, e-commerce, liczby potwierdzone przez klienta; ponad 450 000 napisanych testów automatycznych, stan na wrzesień 2026