Witam, dzisiaj przestudiujemy bardzo ciekawy i co najważniejsze poszukiwany temat na rynku pracy - REST. Omówienie REST podzielimy na trzy części:
W pierwszej części poruszymy historię REST i opiszemy zasady na jakich opiera się REST.
W drugiej części przyjrzymy się, jak 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 Postman.
Artykuł przeznaczony jest dla czytelnika zaznajomionego z następującymi pojęciami:
HTTP;
Adres URL i URI;
JSON i w mniejszym stopniu XML;
Wstrzyknięcie zależności.
Część 1. Co to jest REST
REST, jak wiele rzeczy w świecie IT, jest akronimem od Representational State Transfer . Jest to styl architektoniczny interakcji pomiędzy komponentami systemu rozproszonego w sieci komputerowej. Mówiąc najprościej, REST definiuje styl interakcji (wymiany danych) pomiędzy różnymi komponentami systemu, z których każdy może być fizycznie zlokalizowany w różnych lokalizacjach. Ten styl architektoniczny reprezentuje spójny zestaw ograniczeń, które są brane pod uwagę przy projektowaniu systemu rozproszonego. Ograniczenia te są czasami nazywane zasadami REST. Jest ich niewiele, tylko 6 sztuk. Porozmawiamy o nich nieco później.
Aplikacje budowane z myślą o REST, tj. które nie naruszają ograniczeń nałożonych przez REST, nazywane są RESTful.
Historia RESTU
Termin REST został ukuty przez Roya Fieldinga, jednego z twórców protokołu HTTP, w jego rozprawie doktorskiej „Style architektoniczne i projektowanie architektur oprogramowania opartego na sieci” w 2000 roku. Można powiedzieć, że termin REST jest wciąż młody, chociaż jego koncepcja leży u samych podstaw sieci WWW. Nie będziemy zagłębiać się w historię pochodzenia tego terminu. Jeśli chcesz zagłębić się w oryginalne źródła, zapoznaj się z rozprawą Fieldinga .
Ograniczenia i zasady REST
Jak wspomniano powyżej, REST definiuje, w jaki sposób komponenty systemu rozproszonego powinny ze sobą współdziałać. Ogólnie rzecz biorąc, dzieje się to poprzez żądanie-odpowiedź. Komponent wysyłający żądanie nazywany jest klientem ; Komponent przetwarzający żądanie i wysyłający odpowiedź do klienta nazywany jest serwerem . Żądania i odpowiedzi są najczęściej wysyłane za pośrednictwem protokołu HTTP (HyperText Transfer Protocol). Zazwyczaj serwer jest rodzajem aplikacji internetowej. Klientem może być nie byle co, ale całkiem sporo. Na przykład aplikacja mobilna żądająca danych z serwera. Lub przeglądarka wysyłająca żądania ze strony internetowej do serwera w celu pobrania danych. Aplikacja A może żądać danych od aplikacji B. Wtedy A jest klientem w stosunku do B, a B jest serwerem w stosunku do A. Jednocześnie A może przetwarzać żądania od C, D, D itd. W tym przypadku aplikacja A jest zarówno serwerem, jak i klientem. Wszystko zależy od kontekstu. Jedno jest jasne: 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 żądanie-odpowiedź, jest systemem REST (lub RESTful). Aby system można było uznać za RESTful, musi „pasować” do sześciu ograniczeń REST:
1. Przeniesienie architektury na model klient-serwer
Podstawą tego ograniczenia jest różnicowanie potrzeb. Konieczne jest oddzielenie potrzeb interfejsu klienta od potrzeb serwera przechowującego dane. Ograniczenie to zwiększa przenośność kodu klienta na inne platformy, a uproszczenie części serwerowej poprawia skalowalność systemu. Już samo rozróżnienie pomiędzy „klientem” a „serwerem” pozwala im rozwijać się niezależnie od siebie.
2. Brak kondycji
Architektura REST wymaga spełnienia następującego warunku. Pomiędzy żądaniami serwer nie musi przechowywać informacji o stanie klienta i odwrotnie. Wszystkie żądania od klienta muszą być tak skonstruowane, aby serwer otrzymał wszystkie informacje niezbędne do realizacji żądania. W ten sposób zarówno serwer, jak i klient mogą „zrozumieć” każdy otrzymany komunikat, bez polegania na poprzednich komunikatach.
3. Buforowanie
Klienci mogą buforować odpowiedzi serwera. Te z kolei muszą być jawnie lub pośrednio oznaczone jako buforowane lub niemożliwe do buforowania, aby klienci nie otrzymywali nieaktualnych lub nieprawidłowych danych w odpowiedzi na kolejne żądania. Właściwe wykorzystanie buforowania pomaga całkowicie lub częściowo wyeliminować niektóre interakcje klient-serwer, co dodatkowo zwiększa wydajność i rozszerzalność systemu.
4. Jednolitość interfejsu
Podstawowe wymagania architektury REST obejmują ujednolicony, spójny interfejs. Klient musi zawsze zrozumieć, w jakim formacie i na jakie adresy potrzebuje wysłać żądanie, a serwer z kolei musi również zrozumieć, w jakim formacie powinien odpowiedzieć na żądania klienta. Jest to ujednolicony format interakcji klient-serwer, który opisuje co, gdzie, w jakiej formie i jak wysłać i stanowi ujednolicony interfejs
5. Warstwy
Warstwy odnoszą się do hierarchicznej struktury sieci. Czasami klient może komunikować się bezpośrednio z serwerem, a czasami może po prostu komunikować się z węzłem pośrednim. Użycie serwerów pośrednich może zwiększyć skalowalność poprzez równoważenie obciążenia i rozproszone buforowanie. Podajmy przykład. Wyobraźmy sobie aplikację mobilną, która jest popularna na całym świecie. Jego integralną częścią jest ładowanie obrazów. Ponieważ istnieją miliony użytkowników, jeden serwer nie byłby w stanie wytrzymać tak dużego obciążenia. Podział systemu na warstwy rozwiąże ten problem. Klient zażąda obrazu od węzła pośredniego, węzeł pośredni zażąda obrazu od serwera, który jest w danej chwili najmniej obciążony i zwróci obraz klientowi. Jeśli buforowanie zostanie prawidłowo zastosowane tutaj na każdym poziomie hierarchii, można osiągnąć dobrą skalowalność systemu.
6. Kod na żądanie (ograniczenie opcjonalne)
Ograniczenie to oznacza, że klient może rozszerzyć swoją funkcjonalność poprzez pobranie kodu z serwera w postaci apletów lub skryptów.
Korzyści z odpoczynku
Aplikacje spełniające wszystkie powyższe ograniczenia mają następujące zalety: niezawodność (brak konieczności przechowywania informacji o stanie klienta, które mogą zostać utracone);
wydajność (ze względu na wykorzystanie pamięci podręcznej);
skalowalność;
przejrzystość systemu interakcji;
prostota interfejsów;
przenośność komponentów;
łatwość wprowadzania zmian;
zdolność do ewolucji, dostosowania się do nowych wymagań.
GO TO FULL VERSION