Tylko do końca lipca możesz skorzystać z opcji DOFINANSOWANIA 60% ceny na dowolne szkolenie! Złóż wniosek

Zapraszamy na darmowy WEBINAR: Podstawy organizacji testów: doświadczenia z projektów – 08.08.2024. Zapisz się.

Metody HTTP

Metody HTTP (Hypertext Transfer Protocol) to zestaw standardowych żądań, które definiują różne operacje, jakie klient może wykonywać na zasobach serwera. Te żądania opisują intencję klienta w odniesieniu do zasobów i wywołują odpowiednie działania na serwerze.

Lista metod HTTP:

  • GET          
  • HEAD       
  • POST        
  • PUT          
  • DELETE
  • OPTIONS
  • TRACE
  • CONNECT
  • PATCH

HTTP vs HTTP2

HTTP to pierwotna wersja protokołu, natomiast HTTP/2 to nowsza wersja z wprowadzonymi usprawnieniami, która oferuje lepszą wydajność. HTTP/2 umożliwia równoczesne przesyłanie wielu żądań, zmniejsza rozmiar przesyłanych danych i umożliwia serwerowi inicjowanie wysyłania danych do klienta przed otrzymaniem żądania. Protokół ten jest również bardziej efektywny i wydajny w porównaniu do starszej wersji, jaką jest HTTP.

Jakie znaczenie mają metody HTTP w testowaniu?

Metody HTTP definiują różne operacje, które można przeprowadzić na zasobie internetowym, takim jak strona web, obraz lub rekord w bazie danych. W kontekście testowania, prawidłowe rozumienie i testowanie tych metod jest kluczem do zapewnienia bezpieczeństwa, wydajności i niezawodności aplikacji. Oto główne aspekty, na które warto zwrócić uwagę:

Bezpieczeństwo:

  • GET: Ponieważ metoda GET jest przeznaczona do pobierania danych, ważne jest upewnienie się, że nie zwraca ona wrażliwych informacji, takich jak hasła czy klucze API. Ponadto warto zwrócić uwagę na potencjalne ujawnienie informacji w URL, gdyż adresy URL często są zapisywane w logach.
  • POST/PUT/PATCH: Te metody służą do wysyłania lub aktualizowania danych. Testerzy powinni upewnić się, że te metody są odpowiednio chronione przed nieautoryzowanym dostępem oraz atakami, takimi jak wstrzykiwanie SQL czy ataki typu CSRF.
  • DELETE: Ta metoda usuwa zasoby. Jest to bardzo ważne, by zapewnić, że tylko odpowiednio uprawnione osoby mogą korzystać z tej metody, aby uniknąć przypadkowego usuwania danych. Ponadto metoda DELETE powinna być odpowiednio zabezpieczona przed atakami, takimi jak ataki siłowe lub manipulacja parametrów.

Wydajność i Optymalizacja:

  • Testerzy powinni zwracać uwagę na czas reakcji serwera na różne metody HTTP. Na przykład, żądania GET mogą być zoptymalizowane pod kątem szybkiego dostępu do cache’owanych zasobów, podczas gdy żądania POST mogą wymagać bardziej złożonego przetwarzania danych.
  • W kontekście testowania wydajności ważne jest także uwzględnienie limitów częstotliwości żądań dla poszczególnych metod, aby uniknąć przeciążenia serwera.

Walidacja Danych i Obsługa Błędów:

  • Metody, takie jak POST, PUT i PATCH, często wymagają przesyłania danych. Testerzy powinni upewnić się, że aplikacja prawidłowo weryfikuje i waliduje te dane przed ich przetworzeniem. Nieprawidłowo przetworzone dane mogą prowadzić do błędów aplikacji, niezgodności danych lub nawet do podatności bezpieczeństwa.
  • Testerzy powinni także zwracać uwagę na odpowiedzi serwera w przypadku błędów. Odpowiednie kody błędów (np. 404 dla „nie znaleziono”, 403 dla „brak dostępu”) oraz jasne komunikaty błędów mogą pomóc użytkownikom zrozumieć problem i podjąć odpowiednie działania.

Idempotentność

  • Idempotentność: Niektóre metody HTTP, takie jak GET, PUT i DELETE, są idempotentne. Oznacza to, że wielokrotne wywołanie tych samych żądań powinno prowadzić do tych samych wyników. W praktyce testowania oznacza to, że ponowne wysłanie tego samego żądania nie powinno powodować nieprzewidywalnych efektów ubocznych ani zmieniać stanu aplikacji w nieoczekiwany sposób.

Oto 20 najpopularniejszych kodów odpowiedzi HTTP

  1. 200 OK
    • Opis: Żądanie zakończyło się sukcesem. Standardowa odpowiedź dla prawidłowych żądań HTTP.
  2. 201 Created
    • Opis: Żądanie zakończyło się sukcesem, a serwer utworzył nowy zasób.
  3. 202 Accepted
    • Opis: Serwer przyjął żądanie, ale nie zostało ono jeszcze przetworzone.
  4. 204 No Content
    • Opis: Serwer przetworzył żądanie, ale nie ma dodatkowych informacji do przesłania w odpowiedzi.
  5. 206 Partial Content
    • Opis: Serwer wysyła tylko część żądanego zasobu, na przykład w odpowiedzi na żądanie zakresu.
  6. 301 Moved Permanently
    • Opis: Żądany zasób został trwale przeniesiony pod inny adres URL.
  7. 302 Found (lub „Temporary Redirect”)
    • Opis: Żądany zasób został tymczasowo przeniesiony pod inny adres URL.
  8. 303 See Other
    • Opis: Odpowiedź na żądanie można znaleźć pod innym adresem URL i powinna być pobrana przy użyciu metody GET.
  9. 304 Not Modified
    • Opis: Zasób nie został zmieniony od ostatniego żądania. Często używane z mechanizmami buforowania.
  10. 400 Bad Request
    • Opis: Żądanie nie może być przetworzone przez serwer z powodu niewłaściwej składni.
  11. 401 Unauthorized
    • Opis: Żądanie wymaga uwierzytelnienia. Użytkownik powinien się zalogować.
  12. 403 Forbidden
    • Opis: Serwer rozumie żądanie, ale odmawia jego obsługi.
  13. 404 Not Found
    • Opis: Serwer nie może znaleźć żądanego zasobu.
  14. 405 Method Not Allowed
    • Opis: Metoda żądania jest niedozwolona dla żądanego zasobu.
  15. 406 Not Acceptable
    • Opis: Serwer nie jest w stanie wyprodukować odpowiedzi pasującej do listy wartości podanych w nagłówkach żądania.
  16. 408 Request Timeout
    • Opis: Serwer czekał zbyt długo na zakończenie żądania.
  17. 409 Conflict
    • Opis: Żądanie nie może być zakończone z powodu konfliktu z bieżącym stanem zasobu.
  18. 500 Internal Server Error
    • Opis: Błąd wewnętrzny serwera uniemożliwiający przetworzenie żądania.
  19. 501 Not Implemented
    • Opis: Serwer nie rozpoznaje metody żądania lub nie jest w stanie zrealizować żądania.
  20. 503 Service Unavailable
    • Opis: Serwer nie jest w stanie przetworzyć żądania z powodu tymczasowego przeciążenia lub konserwacji.

Znajomość powyższych kodów odpowiedzi jest niezbędna dla developerów i testerów, aby zrozumieć interakcje między klientem a serwerem oraz potencjalne problemy, które mogą wystąpić podczas komunikacji w aplikacjach internetowych.

Notatka o autorze:

Zajmuję się testowaniem, zabezpieczaniem i zapewnianiem jakości oprogramowania od ponad 13 lat. Rozpocząłem swoją karierę od testów manualnych i analizy biznesowo-technicznej. Obecnie prowadzę firmę Quality Island, która zajmuje się szeroko pojętym testowaniem oprogramowania oraz szkoleniami dla przyszłych i obecnych testerów oprogramowania. Moją specjalnością są testy automatyczne aplikacji webowych oraz budowa procesów automatyzacji i robotyzacji. Od 8 lat prowadzę aktywnie szkolenia oraz konsultacje z tych tematów i wykonuję zlecenia dla firm trzecich jako konsultant, ekspert oraz audytor. Współpracuję również z firmami jako osoba do rekrutacji i weryfikacji technicznych. Interesują mnie głównie tematy związane z architekturą IT oraz zagadnienia DevOps/TestOps, ponieważ ściśle wiążą się z zapewnianiem jakości oprogramowania.

 

Tomasz Stelmach

CEO&Founder

 

0 komentarzy

Wyślij komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *