Zaczniemy od podstawowego pytania, o definicje. Co to jest…
REST
Polskie tłumaczenie wydaje się być takim niezręcznym… choć oczywiście dosłownym. Representational state transfer czyli zmiana stanu poprzez reprezentacje lub też reprezentatywny transfer stanu. REST definiuje zestaw ograniczeń i możliwości do budowania usług internetowych, dostępnych poprzez protokół HTTP.
RESTful API
To można nazwać zestawem do manipulowania zasobami sieciowymi za pomocą architektury… i właśnie, to nie jest dobre słowo, choć widziałem, że nie raz było wykorzystywane. Otóż REST to nie jest architektura, to raczej opis sposobu działania. A RESTful API to wykorzystanie tego sposobu do komunikacji. Dzięki temu można operować na zasobach sieciowych w sposób zdefiniowany.
CRUD
To skrót od Create, Read/Retrieve, Update i Delete/Destroy. Cztery podstawowe czynności, które możemy – między innymi oczywiście – wykonać za pomocą REST. To najczęściej stosowane operacje, dlatego doczekały się własnego skrótowca. Często odnosi się CRUD do systemów bazodanowych, i zazwyczaj tak jest, ale nie jest to konieczność.
Metody REST
Ostatnia rzecz, to lista metod, które oficjalnie wspierane są przez REST. Oficjalnie – czyli zostały zapisane w RFC. To nie znaczy, że każdy serwer zapewnia te metody i na to trzeba uważać, jeżeli chcemy trochę poszaleć. Najbardziej znane są GET i POST. PHP zapewnia nawet specjalne zmienne globalne, aby dostać się do danych, które są w ten sposób przekazywane ($_GET i $_POST). Czasami stosujemy jeszcze DELETE i PUT. Ale to nie wszystko, są inne, nieco bardziej zapomniane. Dostępne metody to:
Metoda | Opis | Uwagi |
---|---|---|
GET | Żąda pobrania określonego zasobu | Ta metoda powinna tylko pobierać dane, wykluczony jest jakikolwiek zapis czy aktualizacja. Oczywiście może się zdarzyć, że na serwerze coś będzie zapisywane z tej okazji, ale nie jest to problem/sprawa programisty, który używa tej metody – z jego punktu widzenia jest to tylko pobranie zasobu |
POST | Służy do zapisu określonego zasobu | Ta metoda powinna być zastosowana, jeżeli do naszego zbioru, chcemy dodać kolejny element. Ta metoda, rzecz jasna, dokonuje zapisu i musimy być tego świadomi. |
DELETE | Służy do usuwania określonego zasobu | Jak łatwo się domyślić, dzięki tej metodzie usuwamy konkretny element z naszego zbioru. Jak wyżej, ta metoda też dokonuje zapisu, konkretnie – usunięcia. |
PUT | Służy do uaktualnienia elementu | Wykorzystując tę metodę, aktualizujemy element. Dwie uwagi – element aktualizujemy całościowo oraz, zazwyczaj, jeżeli nie ma elementu do aktualizacji, to jest tworzony nowy. |
PATCH | Służy do częściowego uaktualnienia elementu | Wyżej zaznaczyłem, że metoda PUT powinna być stosowana przy aktualizacji całego elementu. Jeżeli chcemy dokonać częściowej aktualizacji, użyjemy do tego metody PUT. Ta metoda może, ale nie musi (ze względu na częściowe dane) stworzyć nowy element, jeżeli nie ma tego, który akualizujemy. Oczywiście połączenie jest identyfikowane przez element do którego się odwołujemy. |
OPTIONS | Wysyła prośbę o informacje na temat połączenia | Ta metoda służy do wysłania prośby o informacje na temat opcji komunikacyjnych dostępnych w łańcuchu żądania/odpowiedzi. Metoda ta pozwala klientowi na określenie opcji i/lub wymagań związanych z danym elementem lub możliwościami serwera, bez pobierania danego elementu czy ustanowienia innego połączenia z nim. |
HEAD | Pobranie nagłówków określonego zasobu | Ta metoda, co do zasady, jest identyczna z GET. Z tą różnicą, że nie może zwrócić żadnej treści elementu a tylko i wyłącznie nagłówki, które wysłałaby przed treścią żądanego elementu. Metoda ta jest często używana do testowania linków pod kątem ważności, dostępności i ostatnich modyfikacji. |
TRACE | Metoda do testowania zapytań | To bardzo ciekawa metoda, która w swojej zawartości, powinna zwrócić całe zapytanie. Dzięki temu możemy śledzić/diagnozować jak serwery pośredniczące modyfikują nasze żądanie, jak otrzymuje je serwer docelowy. |
CONNECT | Służy do otwierania połączenia | Specyfikacja REST zastrzega nazwę tej metody do użycia z proxy, który może dynamicznie przełączać się na tunel SSL. Pozawala to na przykład użycie szyfrowanego połączenia SSL (https) przez niezaszyfrowane połączenie proxy (http). Z tego, raczej, nie będziemy korzystać. |
Mam nadzieję, że teraz Ci, którzy tych metod nie znali, zrzucą z głowy ciężar $_GET i $_POST, które niczym kamień u nogi utrudniają dostrzeżenie szerszej perspektywy 🙂 Ale nasuwa się jedno pytanie…
A jak z tego skorzystać w PHP?
Rozpoznanie metody, którą wysłano zapytanie, jest dosyć proste. Nazwa metody znajdziecie tak:
1 |
$_SERVER['REQUEST_METHOD'] |
co pozwala na proste konstrukcje typu:
1 2 3 4 5 |
switch( $_SERVER['REQUEST_METHOD'] ) { case 'GET': case 'POST': case 'HEAD': ... |
Ale skąd te dane? Ano, elementy <form> oficjalnie udostępniają tylko dwie metody – GET i POST. Stąd też zmienne $_GET i $_POST w PHP. Można to obejść, „tunelując” metodę przez POST i podając właściwą metodę w określonym ukrytym polu, np:
1 |
<input type="hidden" name="_method" value="PUT"> |
i od nas zależy, jak to zinterpretujemy.
Dodatkowo, protokół XMLHttpRequest (czyli Ajax), zezwala na metody GET, POST, PUT i DELETE w większości współczesnych przeglądarek (IE, choć to mało współczesne, ale jest, Edge, Chrome, Opera, Firefox, Safari), więc mamy szersze pole do popisu. Możemy założyć, że każda przeglądarka, która wspiera XMLHttpRequest advanced features (kiedyś – XMLHttpRequest Level 2), musi wspierać te metody.
Problemy…
Napisałem, że możemy sobie „tunelować” zapytania przez $_POST i tyle. Że możemy sobie interpretować. Ale czy aby na pewno? Z jednej strony – tak! Ale z drugiej, nie jest to wcale takie oczywiste. Dlaczego? Ano… metoda POST zezwala na użycie cache. A np. metody PUT i DELETE – nie zezwalają na korzystanie z cache. Może to prowadzić do kłopotów. Może nie w małej aplikacji. Ale w czymś większym, z dużym obciążeniem? Na pewno. Dlatego pozostawiam Was z dwoma radami:
- Raczej starajcie się używać różnych metod tam, gdzie są one wspierane.
- OSTROŻNIE!