Jakub Raczkowski 
Powoli zaczynamy wychodzić poza ramy localhosta i zaglądać do czeluści Internetu. W tym odcinku serii „Czym jest…?” wyjaśnimy czym dokładnie jest i jakie ma zastosowanie REST API.
Uwaga! W tej serii zajmuję się opisowym przedstawieniem tematu, a celem jest zapoznanie z zagadnieniem w sposób luźny i zrozumiały dla nowicjusza. W związku z tym wiele elementów siłą rzeczy musi zostać pominiętych. Tych z was, którzy chcieliby się dowiedzieć więcej, zapraszam do źródeł na końcu artykułu.
Czy zastanawialiście się kiedyś jak działa Internet?
.
.
.
Hmm, chociaż to może zbyt duże uogólnienie, zatem pozwólcie mi doprecyzować:
Co tam się dzieje „w środku” kiedy wpiszemy adres www i wciśniemy Enter?
Cóż, trochę tego jest. Wpierw przeglądarka musi dostać konkretny adres IP więc wysyła zapytanie do serwera DNS. Kiedy już dostanie ukochane cyferki, nadaje tam wiadomość z prośbą o przesłanie dostępnej zawartości: kodu html, obrazka czy innego pliku. Następnie docelowy serwer obsługuje to żądanie i jeśli wszystko zadziała, to wysyła wiadomość zwrotną z pożądanym contentem, która zostaje obsłużona przez naszą przeglądarkę. Jeśli ta dostanie plik .html to wyrenderuje nam stronę www, ostyluje za pomocą dołączonego CSS-a i opcjonalnie odpali skrypty JavaScript.
GOTOWE!
Dobrze, skoro mamy ogarnięte jak to wygląda od strony użytkownika, to teraz skupmy się na drugim końcu kija – serwerze. A raczej serwerach, bo zazwyczaj mamy do czynienia z dwoma: frontendowym i backendowym.
Front ubiera pożądaną zawartość w ładne ciuszki i sprawia, że miło wygląda dla oka i aż chce się klikać. Natomiast nawet najpiękniejsza strona nie zatrzyma nas na dłużej, jeśli będzie pozbawiona treści. A ta jest przygotowywana właśnie przez backend.
Podsumowując*: użytkownik wysyła zapytanie do frontu, następnie front do backendu, potem front „ozdabia” tę surową odpowiedź i wysyła z powrotem do klienta strony.
(*) i zakładając, że mówimy o dynamicznie zmieniającym się contencie a nie jakimś statycznym pliku, który może zostać obsłużony bezpośrednio przez front
Ok, jasne. Tylko gdzie tu ten REST?
Zanim przejdziemy do sedna wpisu, chciałbym mieć pewność, że na pewno wiesz czym jest 'Interfejs’.
Przytoczony przykład z IntelliJ to tylko wizualizacja interfejsu w Javie, która pokazuje jak go napisać, ale nie tłumaczy po co.
We wpisie SOLIDne programowanie mówiłem, że OOP opiera się na abstrakcji, że lepiej typować po interfejsie niż ograniczać się do konkretnej klasy/implementacji. Ale tak właściwie dlaczego?
Interfejs == Standard
Dodając do własnego projektu jakiś interfejs określamy zasady na jakich będzie ów projekt (albo jego część) pracować. Jeśli robimy prosty edytor tekstu to może on mieć interfejs z dwiema metodami:
boolean save();
void open();Same w sobie nic nie robią, ot dają wskazówkę jaka będzie ich funkcja. To od programisty zależy jak te metody zostaną zaimplementowane. Jeden będzie zapisywał do pliku txt, inny do pdf-a, trzeci od razu wyśle to do bazy danych. Każdy robi po swojemu, ale jednocześnie każdy trzyma się ustalonych zasad.
Taki właśnie jest REST.
To pewien rodzaj standardu dostępu do danych.
REST (skrót od „Representational State Transfer„) to API czyli „Application Programming Interface” – interfejs dający programistom dostęp do naszej aplikacji. Dzięki metodom jakie sami zadeklarujemy, inni developerzy zyskają możliwość korzystania z naszego softu.
REST jako standard ma konkretne metody HTTP, z których możemy skorzystać (ze wszystkich albo z wybranych):
- GET (ang. „brać”)
- POST (ang. „wysyłać”)
- PUT (ang. „wkładać”)
- PATCH (ang. „łatać”)
- DELETE (ang. „usuwać”)
Ich nazwy mówią same za siebie, choć nic nie stoi na przeszkodzie* abyśmy zrobili tak, że to POST usuwa elementy, a DELETE je tworzy.
(*) no może poza tłumem wku%wionych użytkowników naszego API, który pochodniami i widłami wybije nam takie żarty z głowy.
Jednak REST to nie tylko nazwy metod, ale również zasady dotyczące tego jak mają działać. Mianowicie:
- Bezstanowość – metody nic nie zapamietują, ani użytkownika, ani tego co już zrobił (od tego są pliki cookies).
- „Keszowanie” – popularne użycia metod mogą być przerzucone do schowka (ang. „cache”) w celu szybszego obsłużenia.
- Podział na klienta i serwer, którzy sa od siebie niezależni (w przeciwnieństwie do np. protokołu P2P gdzie każdy jest jednocześnie klientem i serwerem).
- Warstwowość – w skrócie „klient nasz pan”: klient wysyła żądanie i nie interesuje go praca serwera tylko sam rezultat. Klient ma widzieć tylko wierzchnią warstwę aplikacji.
- Kod na żądanie – opcjonalnie można wysłać kawałek kodu (JavaScript), który ma zostać uruchomiony już po stronie klienta.
- Jednolity standard – REST-owe metody są zawsze takie same, bez względu na rodzaj klienta (desktop, mobile, konsola itp.)
W tym miejscu nie sposób nie napomknąć o bardzo użytecznym narzędziu do poznawania i testowania REST-owych metod jakim jest:
POSTMAN
Zwykle przeglądarka internetowa jest w stanie wywoływać jedynie metodę GET – wchodzimy na stronę i od razu pobieramy jej zawartość, nie możemy ot tak sobie walnąć tam PUT-a i podmienić treści na taką jaka nam pasuje.
I ok, nie-technicznym użytkownikom nie ma co komplikować życia. Ale jeśli dev albo tester będą chcieli sprawdzić dane API to taki nóż do masła nie wystarczy.
Potrzebny będzie szwajcarski scyzoryk: Postman.
Postman występuje w dwóch formach: albo jako rozszerzenie do przeglądarki, albo w tradycyjnej wersji desktopowej. Funkcji jest tam tyle, że ich opisanie wymagałoby osobnego artykułu, ale na dzisiaj skoncentrujmy się tylko na fakcie, że sami możemy wybierać metody API do użycia – przy tej samej zawartości zapytania inny efekt otrzymamy kiedy zawołamy GET-a, a inny dla DELETE-a. Bardzo wygodne i niesamowicie użyteczne.
Na koniec
Jeszcze rok temu, patrząc na wymagane technologie w ofertach pracy, myślałem, że REST jest pewnie jakimś zewnętrznym programem (jak Maven), albo zestawem bibliotek do użycia (jak JUnit) i dopiero po bliższym przyjrzeniu okazało się, że:
REST to interfejs
REST to standard
REST to architektura
A co ciekawe, REST nie jest jedynym koniem w tym wyścigu. Jako, że jego definicja została sprecyzowana dopiero w roku 2000, a Internet jest kilka dekad starszy, to oczywistym musi być, że wcześniej korzystano z czegoś innego. Tym czymś był tak zwany:
SOAP
Simple Object Access Protocol
Różnic trochę jest, ale REST wygryzł kolegę ze stołka, głównie dlatego, że działa szybciej i jest łatwiejszy do zrozumienia/opanowania/użycia. Mimo to SOAP wciąż jest gdzie-nie-gdzie wykorzystywany – jeśli zobaczycie go w ofertach pracy to zazwyczaj oznacza to, że chodzi o wewnętrzne sieci większych korporacji z sektora medycznego albo bankowego.
O ile SOAP już powoli odchodzi w zapomnienie to i sam REST też nie może czuć się bezpiecznie, gdyż już na karku czuje ciepły oddech innego zawodnika:
Żeby nie przedłużać, powiem tylko, że GraphQL wybierany jest najczęściej przez wielkie firmy z grubymi milionami użytkowników i miliardami zapytań każdego dnia (np. Facebook). W takich sytuacjach odchudzenie wiadomości choćby tylko o jeden znak przekłada się na realne oszczędności w pracy serwerów. GraphQL jest właśnie takim rozwiązaniem w którym każde wywołanie jego metod ma zwracać tylko pożądaną zawartość i ani literki więcej. Niestety przy okazji zauważalnie trudniej się go nauczyć niż REST-a.
Na dzisiaj chyba wystarczy informacji. Dziękuję za uwagę i zapraszam już za kilka dni na wpis poświęcony architekturze oprogramowania: „Czym jest DDD (i CQRS)?”.
Żródła:
Porównanie SOAP/REST/GRAPHQL YT/ANG
