Cześć! Dziś poznamy temat, który jest bardzo ciekawy i, co najważniejsze, bardzo poszukiwany na rynku pracy: REST. Nasz przegląd REST podzielimy na trzy części:
W pierwszej części omówimy historię REST oraz opiszemy zasady, na których REST jest oparty.
W drugim rozważymy, w jaki sposób odbywa się komunikacja między klientem a serwerem za pośrednictwem protokołu HTTP.
W trzecim napiszemy małą aplikację RESTful, którą przetestujemy za pomocą programu o nazwie „Postman”.
Artykuł jest przeznaczony dla czytelników zaznajomionych z następującymi pojęciami:
HTTP
URL i URI
JSON i (w mniejszym stopniu) XML
Wstrzyknięcie zależności
Część 1. Co to jest ODPOCZYNEK?
REST, jak wiele w świecie IT, to akronim. Wywodzi się z „REpresentational State Transfer” . Jest to styl architektoniczny interakcji między składnikami systemu rozproszonego w sieci komputerowej. Mówiąc najprościej, REST określa styl interakcji (wymiany danych) pomiędzy różnymi komponentami systemu, z których każdy może być fizycznie zlokalizowany w różnych miejscach. Ten styl architektoniczny jest spójnym zestawem ograniczeń przestrzeganych podczas projektowania systemu rozproszonego. Te ograniczenia są czasami nazywane przewodnimi zasadami REST. Nie ma ich wiele, tylko 6. Porozmawiamy o nich trochę później.
Aplikacje budowane z myślą o zasadach REST, czyli takie, które nie naruszają ograniczeń REST, nazywane są „RESTful”.
Historia RESTu
Termin REST został wprowadzony przez Roya Fieldinga, jednego z twórców protokołu HTTP, w jego pracy doktorskiej. pracę magisterską zatytułowaną „Style architektoniczne i projektowanie architektur oprogramowania sieciowego” w 2000 r. Chociaż termin REST można nadal nazwać młodym, koncepcja, którą reprezentuje, leży u podstaw sieci World Wide Web. Nie będziemy zagłębiać się w historię tego terminu. Jeśli chcesz zagłębić się w podstawowe źródła, spójrz na rozprawę Fieldinga .
Ograniczenia i zasady REST
Jak wspomniano powyżej, REST określa, w jaki sposób komponenty systemu rozproszonego powinny ze sobą współdziałać. Na ogół dzieje się to w procesie żądanie-odpowiedź. Komponent, który wysyła żądanie, jest nazywany klientem , a komponent, który przetwarza żądanie i wysyła odpowiedź do klienta, jest nazywany serwerem .. Żądania i odpowiedzi przesyłane są najczęściej za pośrednictwem protokołu HTTP. HTTP to skrót od HyperText Transfer Protocol. Zazwyczaj serwer to jakaś aplikacja internetowa. Klientem może być prawie wszystko. Na przykład aplikacja mobilna, która żąda danych z serwera. Lub przeglądarka, która wysyła żądania ze strony internetowej do serwera w celu pobrania danych. Aplikacja A może zażądać danych od Aplikacji B. W tym przypadku A jest klientem w stosunku do B, a B jest serwerem w odniesieniu do A. W tym samym czasie A może przetwarzać żądania od B, C, D itd. W tym przypadku aplikacja A jest zarówno serwerem, jak i klientem. Wszystko zależy od kontekstu. Jedno jest pewne: komponentem wysyłającym żądanie jest klient. Komponentem, który odbiera, przetwarza i odpowiada na żądanie, jest serwer. Jednakże, nie każdy system, którego komponenty komunikują się poprzez proces żądanie-odpowiedź, jest systemem RESTful. Aby system mógł zostać uznany za RESTful, musi być zgodny z sześcioma ograniczeniami REST:
1. Architektura klient-serwer
To ograniczenie dotyczy rozdzielenia obaw. Konieczne jest oddzielenie wymagań interfejsu klienta od wymagań serwera przechowującego dane. To ograniczenie sprawia, że kod klienta jest bardziej przenośny na inne platformy, a uproszczenie strony serwera poprawia skalowalność systemu. Rozróżnienie między „klientem” a „serwerem” pozwala na ich niezależny rozwój.
2. Bezpaństwowcy
Architektura RESTful wymaga spełnienia następujących warunków. W okresie między zapytaniami serwer nie może przechowywać informacji o stanie klienta i odwrotnie. Wszystkie żądania od klienta muszą być skomponowane w sposób, który przekazuje serwerowi wszystkie informacje niezbędne do zrealizowania żądania. W ten sposób zarówno serwer, jak i klient mogą „zrozumieć” każdą otrzymaną wiadomość, bez polegania na poprzednich wiadomościach.
3. Pamięć podręczna
Klienci mogą buforować odpowiedzi serwera. Te z kolei muszą być jawnie lub niejawnie oznaczone jako buforowane lub niebuforowane, aby klienci nie otrzymywali nieaktualnych lub niepoprawnych danych w odpowiedzi na kolejne żądania. Prawidłowe buforowanie pomaga całkowicie lub częściowo wyeliminować niektóre interakcje klient-serwer, dodatkowo zwiększając wydajność i skalowalność systemu.
4. Jednolity interfejs
Podstawowe wymagania architektury RESTful obejmują ujednolicony, jednolity interfejs. Klient musi zawsze rozumieć format i adresy, których musi użyć podczas wysyłania żądania, a serwer z kolei musi również rozumieć format, którego powinien używać, odpowiadając na żądania klienta. Ta spójna interakcja klient-serwer, która opisuje, co, gdzie, w jakiej formie i jak przesyłać dane, jest ujednoliconym interfejsem.
5. Warstwy
Przez warstwy rozumiemy hierarchiczną strukturę sieci. Czasami klient może komunikować się bezpośrednio z serwerem, a czasami po prostu komunikuje się z węzłem pośrednim. Wykorzystanie serwerów pośrednich może zwiększyć skalowalność dzięki równoważeniu obciążenia i rozproszonemu buforowaniu. Podajmy przykład. Wyobraź sobie aplikację mobilną, która jest popularna na całym świecie. Integralną częścią aplikacji jest ładowanie zdjęć. Jego użytkowników liczą miliony, więc pojedynczy serwer nie jest w stanie obsłużyć tak dużego obciążenia. Rozdzielenie systemu na warstwy rozwiąże ten problem. Jeśli klient żąda obrazu z węzła pośredniego, wówczas węzeł pośredni żąda obrazu z serwera, który jest w tej chwili najmniej obciążony i zwraca obraz klientowi. Jeśli buforowanie jest stosowane poprawnie na każdym poziomie hierarchii,
6. Kod na żądanie (opcjonalnie)
To ograniczenie oznacza, że klient może rozszerzyć swoją funkcjonalność, pobierając kod z serwera w postaci apletów lub skryptów.
Zalety architektury RESTful
Aplikacje spełniające wszystkie powyższe ograniczenia mają następujące zalety: niezawodność (brak konieczności zapisywania stanu klienta, który mógłby zostać utracony)
wydajność (dzięki zastosowaniu pamięci podręcznej)
skalowalność
przejrzysta komunikacja
proste interfejsy
ruchliwość
możliwość łatwego wprowadzania zmian
zdolność do rozwoju i dostosowywania się do nowych wymagań
Nasz przegląd REST podzielimy na trzy części:
