Powrót

Typy zapytań HTTP

Wydawać by się mogło, że coś co jest opisane w dokumentacji, używa się zawsze w jeden i ten sam sposób. Z mojego doświadczenia wynika jednak, że również w takich przypadkach pojawiają się burzliwe dyskusje i różnice zdań. Przejdziemy więc przez wszystkie typy zapytań HTTP i omówimy kiedy i jak ich używać oraz jak ich NIE używać.

GET

Najprostszy, a nawet domyślny typ zapytania HTTP (w przypadku używania natywnego fetch w JS). Służy do pobierania danych z serwera.

Tego nie rób: Zwraca się uwagę na to by w parametrach takiego zapytania nie przechowywać poufnych danych (np loginu i hasła) bo są one widoczne w URL. To znaczy, że wystarczy spojrzeć na adres, który zostaje wygenerowany aby móc je odczytać.

Notatka: Nie wszystkie parametry w GET są umieszczane w URL. Pamiętaj, że używając HTTPS, nagłówki (Headers) są szyfrowane. Używa się ich choćby do tego żeby móc się zautoryzować przed serwerem. Używa się do tego zwykle nagłówka Authorization i umieszcza w nim token.

HEAD

Znacznie mniej powszechny, a może być przydatny. Podobnie jak GET, służy do pobierania jakichś informacji, ale w tym przypadku ogranicza je tylko do nagłówków.

Kiedy używać:

• Kiedy chcesz tylko sprawdzić czy zasób istnieje, bez konieczności pobierania jego całej treści.
• Kiedy chcesz sprawdzić czy zasób został zaktualizowany od ostatniego pobierania.
• Upewnić się czy typ danych (content-type) pod danym URL odpowiada temu co chcesz i możesz wyświetlić.
• Sprawdzić czy połączenie z serwerem w ogóle działa.

Tego nie rób: Jeżeli chcesz mieć endpoint do pobierania kompletnych danych, to nie używaj do tego typu HEAD tylko GET.

POST

Służy do wysyłania danych na serwer, zwykle towarzyszących jakiś nowy byt (na przykład post na blogu, użytkownika).

Kiedy używać:

• Przesyłanie danych z formularza, które kończą się tworzeniem nowych dokumentów
• Uploadowanie plików
• Operacje powodujące zmiany stanu na serwerze, na przykład nowe zamówienie w sklepie

Tego nie rób:

• Pobieranie danych za pomocą POST (służy do tego GET)
• Operacje idempotentne czyli trudne słowo określające takie operacje, które wielokrotnie wykonane, zawsze przyniosą taki sam stan.

Wyjaśnię - wyobraź sobie przycisk “Wyczyść filtry” obok filtrowania listy produktów (kategoria produktów, zakres cen i inne takie). Możesz go kliknąć 100 razy, ale efekt zawsze będzie taki sam - wszystkie wybrane filtry znikną. To jest właśnie operacja idempotentna.

Przeciwieństwem byłby przycisk “Dodaj do koszyka”. Za każdym razem gdy go klikniesz, kolejny produkt znajdzie się w Twoim wirtualnym koszyku i zwiększy się cena zamówienia.

PUT

Zwykle używany do aktualizowania istniejących już danych. Warto podkreślić, że chodzi tutaj zazwyczaj o kompletną podmianę danych na nowe. Do zmiany pojedynczych właściwości, teoretycznie należałoby użyć PATH.

Tego nie rób: Choć wydawać by się mogło, że PUT mógłby służyć do logowania, to jest to błędne założenie. Z pozoru logowanie wygląda na akcje idempotentną (wyjaśnienie wyżej) bo za każdym razem jak klikniemy “Zaloguj” to po prostu.. się zalogujemy. Jednak “pod spodem” wydarzy się tworzenie zupełnie nowego tokenu sesji i potencjalnie innych unikatowych informacji. Do logowania najlepszy więc będzie POST.

PATCH

Jak wspomniałem wyżej, wykorzystywany do częściowego aktualizowania treści, na przykład adres e-mail użytkownika, bez zmian w pozostałych danych.

Tego nie rób: Jeżeli na przykład zlecasz zmianę nazwiska jakiejś autorki i chcesz aby zmiana była propagowana na wszystkie jej pozycje, to lepszym wyborem byłby PUT jako, że do zmian wymagany jest szerszy kontekst niż tylko pole nazwiska.

DELETE

Nazwa niemal wyczerpuje temat. Warto jednak pamiętać żeby za żądaniem DELETE faktycznie stało usunięcie jakichś treści, a nie ich ukrycie (na przykład za pomocą jakiejś flagi). Jeżeli nie chcesz kompletnie pozbywać się jakiegoś zasobu, użyj PUT.

CONNECT

Metoda ta używana jest przede wszystkim przy łączeniu się z jakimiś serwerami za pomocą proxy (czyli takiego serwera-pośrednika). Służy ona zabezpieczaniu treści wiadomości przed byciem “podglądanym” lub nawet modyfikowanym przez takie serwery proxy.

Chodzi o to, że używając HTTPS, wiadomość powinna być rozszyfrowana na końcu połączenia, a nie gdzieś po drodze. CONNECT sprawia więc, że między nadawcą (np. przeglądarką), a odbiorcą (serwerem docelowym, na przykład stroną internetową) powstaje połączenie tunelowe.

Od tego momentu serwer proxy tylko przekazuje te pakiety danych, bez wglądu w nie. Działa tylko jako przewód.

Ważne jest aby zrozumieć, że to nie my po stronie frontend’u musimy implementować takie zapytanie. To serwer proxy, widząc zapytanie HTTPS do zewnętrznej strony (np. Facebook) sam ogarnia temat. Oczywiście musi mieć zaimplementowaną obsługę takich zapytań. W przeciwnym wypadku - połączenie się nie uda!

TRACE

Trochę dalej pozostajemy w tematyce serwerów proxy. Metoda TRACE, jak sama nazwa wskazuje, służy do daje możliwość podejrzenia co się z nim dzieje z requestem “po drodze”. A co może się dziać? Na przykład niektóre serwery mogą doklejać dodatkowe ciasteczka, modyfikować nagłówki.

W praktyce korzysta się z tego tylko do diagnostyki i debugowania aplikacji, nie na porządku dziennym.

Na to uważaj: Korzystając z TRACE na produkcji, sprawiasz, że potencjalnie wrażliwe dane zawarte w nagłówkach lub ciasteczkach mogą wyciec. Albo go nie włączaj albo upewnij się, że odfiltrowuje informacje, które nie powinny trafić w niepowołane ręce.

OPTIONS

To metoda, która w teorii powinna zwrócić nam informacje jakiego typu żądania możemy kierować do danego serwera (całego lub tylko wybranego zasobu). Piszę “w teorii” bo to jakie informacje zostaną zwrócone, zależy w pełni od zastosowanej implementacji. Może służyć jako upewnienie się, że dokumentacja jakiegoś REST API odpowiada stanowi faktycznemu.

OPTIONS używane jest też w automatycznie generowanych zapytaniach “preflight” kierowanych pod inny origin (domenę). Sprawdzają w ten sposób czy request może być obsłużony.

Powrót