Untitled

1
•
Representational State Transfer (REST) jest to styl architektury oprogramowania bazującego
na sieci WWW.
•
REST opisuje skoordynowany zbiór ograniczeń i wskazówek odnośnie budowy komponentów
wchodzących w skład większego, rozproszonego systemu. Zbiór ten ma prowadzić do
budowania aplikacji, które będą mogły przetworzyć większą ilość informacji będąc przy tym
łatwiejsze w zarządzaniu jak i rozbudowie.
2
•
REST został zaproponowany w roku 2000 przez Roya Fieldinga w jego pracy doktorskiej pod
tytułem „Style architektury oraz konstrukcja oprogramowania bazującego na sieci”. REST
został tworzony oraz rozwijany równolegle z HTTP 1.1.
3
•
O aplikacjach (systemach), które spełniają wszystkie wymagania architektury REST mówimy,
że są to aplikacje typu RESTful.
•
Aplikacje tego typu przeważnie, lecz nie zawsze, komunikują się poprzez protokół HTTP przy
wykorzystaniu słów kluczowych:
•
•
GET
•
POST
•
PUT
•
DELETE
Interfejsy REST do komunikacji z zewnętrznymi systemami wykorzystują zasoby
identyfikowane przez URI (Uniform Resource Identifier) np. /people/tom, które mogą być
modifyfikowane przez standardowe słowa kluczowe wymienione wyżej.
4
•
Wydajność – interakcje między komponentami mogą być postrzegano jako najważniejszy
czynnik jeśli chodzi o wydajność z punktu widzenia użytkownika,
•
Skalowalność – wsparcie dużej liczby komponentów oraz obsługa interakcji między nimi.
Oprócz komponentów typowo obliczeniowych są to także serwery proxy, bramki, firewalle
itp.
•
Prostota interfejsów – upraszcza integrację między różnymi systemami niezależnie od
użytej technologii,
•
Łatwość modyfikacji – bardzo ważna w czasach ciągle zmieniających się wymagań
stawianych różnym aplikacjom,
•
Widoczność komunikacji między komponentami – ułatwia monitorowanie zarówno
działania samych komponentów jak i komunikacji między serwisem a systemami
zewnętrznymi,
•
Przenośność – możliwość przenoszenia kodu programu razem z danymi,
•
Niezawodność – możliwość ukrycia awarii w taki sposób aby było transparentne dla
użytkownika końcowego
5
•
Właściwości architektury REST:
•
Architektura typu klient – serwer – zunifikowany interfejs oddziela klientów od
serwera. Oznacza to, że klient nie jest powiązany np. z żadnym rozwiązaniem
bazodanowym, które działa w powiązaniu z serwerem co pozwala na przykład na
większą przenośność kodu. Z kolei serwer nie jest powiązany z interfejsem
użytkownika, więc mogą być prostsze a co za tym idzie bardziej skalowalne.
•
Bezstanowość – serwer nie przechowuje kontekstu klienta. Oznacza to, że każde
przychodzące żądanie zawiera komplet informacji potrzebny do jego
przetworzenia. Sesja klienta jest utrzymywania po stronie klienta. Istnieje
możliwość przetransferowania sesji do innego serwisu (np. bazy danych) aby
umożliwić jej integralność a także możliwość ciągłej autoryzacji.
•
Możliwość wykorzystania pamięci podręcznej (cacheability) – odpowiedzi serwera
mogą być przechowywane w pamięci podręcznej klientów a także w
komponentach pośrednich (np. serwerach proxy). Odpowiedzi muszą zawierać
informację, czy mogą być przechowywane w pamięci podręcznej czy też nie. Złe
zarządzanie pamięcią może prowadzić do nieoczekiwanych wyników na odebrania
odpowiedzi z nieaktualnymi danymi. Przechowywanie podręczne pozwala
zrezygnowanie z części komunikacji między klientem a serwerem co prowadzi do
większej wydajności jak i skalowalności.
•
Architektura wielowarstwowa – klient korzystający z serwisu nie wie, czy
podłączony jest bezpośrednio do bazy danych czy też poprzez szereg komponentów
pośrednich. Serwis jest dla klienta „przezroczysty”. Można przez to
zaimplementować szereg rozwiązań poprawiających wydajność np. load balancery
czy też serwisy współdzielące pamięć podręczną.
•
Jednolity interfejs – fundament serwisów typu REST, upraszcza oraz rozdziela
architekturę co umożliwia niezależny rozwój każdego z komponentów systemu.
6
•
Właściwości jednolitego interfejsu:
•
Jednoznaczna identyfikacja zasobów – zasoby są niezależne od ich reprezentacji
zwracanych do klienta na przykład serwer zwraca zasoby w postaci np. XML lub
JSON, kiedy serwer wewnętrzne przechowuje te zasoby w innej postaci,
•
Manipulacja zasobami poprzez reprezentacje zasobów – kiedy klient pobrał
reprezentację pewnego zasobu, ma komplet informacji, które pozwalają mu na
modyfikację bądź usunięcie tego zasobu
•
Zawartość komunikatów określa sposób ich przetwarzania – na przykład klient ma
informację, którego parsera użyć aby przetworzyć dane zawarte w komunikacie.
Odpowiedzi zawierają także informacje czy mogą być przechowywane podręcznie
czy też nie.
•
HATEOAS – przechodzenie między stanami tylko poprzez udostępnione akcje – klient
wykonuje zmianę stanu tylko poprzez akcje, które są dynamicznie udostępniane
przez serwis.
7
•
Serwisy typu REST oparte o HTTP charakteryzują się:
•
Adresem bazowym (URI) np. http://example.com/resources/
•
Typ danych użyty w komunikacji – przeważnie JSON lecz może być użyty np. XML,
•
Standardowe metody HTTP (GET, PUT, POST, DELETE)
•
Odnośniki HTTP do zasobów
8
•
Serwis typu RESTful jest bezstanowy i nie zarządza stanem aplikacji dla żadnego klienta.
•
Żądania nie mogą być zależne od poprzednich.
•
Serwis traktuje każde żądanie niezależnie.
9
•
Aby przetworzyć żądania typu stanowego serwer musi zapamiętać ostatni identyfikator
PersonID, który został przetworzony przez klienta. Innymi słowy musi zapamiętać stan.
•
Dobrą praktyką jest tworzenie serwisów bezstanowych, które nie polegają na poprzednich
żądaniach. Są one łatwiejsze do utrzymania oraz skalowania, także odpowiadają szybciej na
nadchodzące żądania.
10
11
12
13
•
Główną różnicą między PUT i POST jest to, że metoda PUT jest idempotentna a POST nie.
Oznacza to, że nie ważne ile razy metoda PUT zostanie wykonana, rezultat zawsze będzie
ten sam. Wywołanie metody POST wielokrotnie doprowadzi na przykład do wielokrotnego
utworzenia nowego rekordu na serwerze.
•
Metoda PUT wymaga także podania pełnego identyfikatora URI zasobu. Oznacza to, że klient
powinien potrafić utworzyć identyfikator do zasobu nawet jeśli ten zasób jeszcze nie istnieje.
Jest to możliwe jeśli w gestii klienta leży tworzenie unikalnych identyfikatorów dla
zasobów. W przeciwnym wypadku klient jest zmuszony do użycia metody POST.
14
Reprezentacja zasobu odzwierciedla aktualny stan zasobu oraz jego atrybuty w momencie w którym
aplikacja kliencka odwołała się do niego.
Po lewej przykład reprezentacji w formacie JSON, po prawej reprezentacja tego samego zasobu w
formacie XML.
15
•
Pamięć podręczna służy do przechowywania wygenerowanych wyników oraz używania ich
zamiast generowania nowych zapytań. Pamięć podręczna może być zaimplementowana
zarówno po stronie klienta, serwera jak i po stronie komponentu pośredniego (np. serwera
proxy). Pamięć podręczna jest jednym z lepszych sposobów podniesienia wydajności
komunikacji lecz jeśli nie jest zaimplementowana poprawnie może prowadzić do
generowania nieprawidłowych rezultatów.
16
•
W odróżnieniu od web serwisów bazujących na SOAP, nie ma oficjalnego standardu
określającego serwisy typu REST, ponieważ REST określa styl architektoniczny podczas gdy
SOAP jest protokołem.
•
Podczas gdy REST nie jest standardem, jego implementacje wykorzystują standardy takie jak
HTTP, URI, JSON i XML.
•
Porównanie żądania SOAP i REST.
Po prawej porównanie tego samego żądania, na górze SOAP, na dole REST. Należy zwrócić uwagę
na wielkość żądania. W SOAP zarówno żądania jak i odpowiedzi zawsze muszą być opakowane w
tzw. kopertę (envelope), która znacznie zwiększa rozmiar komunikatu przesyłanego przez sieć.
17
18