Reprezentacyjny transfer państwowy - Representational state transfer

„REST” przekierowuje tutaj. W przypadku innych zastosowań zobacz Odpoczynek .

Reprezentacyjny transfer stanu ( REST ) to styl architektoniczny oprogramowania, który został stworzony, aby kierować projektowaniem i rozwojem architektury sieci WWW . REST definiuje zestaw ograniczeń dotyczących sposobu, w jaki powinna zachowywać się architektura rozproszonego systemu hipermedialnego na skalę internetową , takiego jak sieć Web. Styl architektoniczny REST kładzie nacisk na skalowalność interakcji między komponentami, jednolite interfejsy , niezależne wdrażanie komponentów oraz tworzenie architektury warstwowej w celu ułatwienia buforowania komponentów w celu zmniejszenia opóźnień odczuwanych przez użytkownika , wymuszenia bezpieczeństwa i enkapsulacji starszych systemów .

REST jest stosowany w całej branży oprogramowania i jest powszechnie akceptowanym zestawem wytycznych dotyczących tworzenia bezstanowych, niezawodnych internetowych interfejsów API . Internetowy interfejs API, który przestrzega ograniczeń REST, jest nieformalnie określany jako RESTful . Internetowe interfejsy API zgodne ze standardem REST są zazwyczaj luźno oparte na metodach HTTP umożliwiających dostęp do zasobów za pomocą parametrów zakodowanych w adresie URL oraz użycie formatu JSON lub XML do przesyłania danych.

„Zasoby internetowe” zostały po raz pierwszy zdefiniowane w sieci WWW jako dokumenty lub pliki identyfikowane przez ich adresy URL . Obecnie definicja jest znacznie bardziej ogólna i abstrakcyjna i obejmuje każdą rzecz, jednostkę lub czynność, którą można zidentyfikować, nazwać, zaadresować, obsłużyć lub wykonać w jakikolwiek sposób w sieci. W usłudze sieci Web RESTful żądania kierowane do identyfikatora URI zasobu wywołują odpowiedź z ładunkiem sformatowanym w formacie HTML , XML , JSON lub innym formacie. Na przykład odpowiedź może potwierdzić, że stan zasobu został zmieniony. Odpowiedź może również zawierać łącza hipertekstowe do powiązanych zasobów. Najpopularniejszym protokołem dla tych żądań i odpowiedzi jest HTTP. Zapewnia operacje ( metody HTTP ), takie jak GET, POST, PUT i DELETE. Korzystając z bezstanowego protokołu i standardowych operacji, systemy RESTful dążą do wysokiej wydajności, niezawodności i możliwości rozwoju poprzez ponowne wykorzystanie komponentów, którymi można zarządzać i aktualizować bez wpływu na system jako całość, nawet gdy jest on uruchomiony.

Celem REST jest zwiększenie wydajności, skalowalności, prostoty, modyfikowalności, widoczności, przenośności i niezawodności. Osiąga się to poprzez przestrzeganie zasad REST, takich jak architektura klient-serwer, bezstanowość, buforowanie, użycie systemu warstwowego, obsługa kodu na żądanie i użycie jednolitego interfejsu. Zasady te muszą być przestrzegane, aby system mógł zostać sklasyfikowany.

Etymologia

Termin transfer państwowy przedstawicielski został wprowadzony i zdefiniowany w 2000 r. przez Roya Fieldinga w swojej rozprawie doktorskiej. Termin ten ma na celu wywołanie obrazu tego, jak zachowuje się dobrze zaprojektowana aplikacja internetowa: jest to sieć zasobów internetowych (wirtualna maszyna stanu ), w której użytkownik przechodzi przez aplikację, wybierając łącza (np. http://www.przykład .com/articles/21), w wyniku czego następna reprezentacja zasobu (następny stan aplikacji) jest przesyłana do klienta i renderowana dla użytkownika.

Historia

Roy Fielding przemawia na OSCON 2008

Sieć zaczęła wchodzić do codziennego użytku w latach 1993-4, kiedy zaczęły pojawiać się strony internetowe do użytku ogólnego . W tamtym czasie istniał tylko fragmentaryczny opis architektury sieci Web, aw branży naciskano na uzgodnienie jakiegoś standardu protokołów interfejsu sieci Web. Na przykład kilka eksperymentalnych rozszerzeń zostało dodanych do protokołu komunikacyjnego (HTTP) w celu obsługi serwerów proxy i proponowano więcej rozszerzeń, ale istniała potrzeba formalnej architektury sieci Web, za pomocą której można by ocenić wpływ tych zmian.

Wspólnie grupy robocze W3C i IETF rozpoczęły prace nad stworzeniem formalnych opisów trzech podstawowych standardów sieci: URI , HTTP i HTML . Roy Fielding był zaangażowany w tworzenie tych standardów (w szczególności HTTP 1.0 i 1.1 oraz URI), a w ciągu następnych sześciu lat opracował styl architektoniczny REST, testując jego ograniczenia na standardach protokołów internetowych i używając go jako środka do zdefiniowania ulepszenia architektoniczne — oraz w celu identyfikacji niezgodności architektonicznych. Fielding zdefiniował REST w swojej pracy doktorskiej z 2000 r. „Style architektoniczne i projektowanie architektury oprogramowania opartego na sieci” na Uniwersytecie Kalifornijskim w Irvine .

Aby stworzyć styl architektoniczny REST, firma Fielding określiła wymagania, które mają zastosowanie podczas tworzenia ogólnoświatowej aplikacji sieciowej, takie jak potrzeba niskiej bariery wejścia, aby umożliwić globalną adopcję. Przebadał również wiele istniejących stylów architektonicznych dla aplikacji sieciowych, identyfikując, które funkcje są współdzielone z innymi stylami, takimi jak buforowanie i funkcje klient-serwer, oraz te, które są unikalne dla REST, takie jak koncepcja zasobów. Fielding próbował zarówno kategoryzować istniejącą architekturę obecnej implementacji, jak i identyfikować, które aspekty powinny być uważane za kluczowe dla behawioralnych i wydajnościowych wymagań sieci.

Ze swojej natury style architektoniczne są niezależne od jakiejkolwiek konkretnej implementacji i chociaż REST został stworzony w ramach opracowywania standardów internetowych, implementacja sieci Web nie spełnia wszystkich ograniczeń w stylu architektonicznym REST. Niedopasowania mogą wystąpić z powodu niewiedzy lub niedopatrzenia, ale istnienie stylu architektonicznego REST oznacza, że ​​można je zidentyfikować, zanim zostaną ustandaryzowane. Na przykład Fielding zidentyfikował osadzanie informacji o sesji w identyfikatorach URI jako naruszenie ograniczeń REST, co może negatywnie wpłynąć na współdzieloną pamięć podręczną i skalowalność serwera. Pliki cookie HTTP naruszały również ograniczenia REST, ponieważ mogą utracić synchronizację ze stanem aplikacji przeglądarki, co powoduje, że są niewiarygodne; zawierają również nieprzezroczyste dane, które mogą stanowić zagrożenie dla prywatności i bezpieczeństwa .

Koncepcje architektoniczne

Model encji-relacyjny koncepcji wyrażony w stylu architektonicznym REST.

Styl architektoniczny REST jest przeznaczony dla aplikacji sieciowych, w szczególności aplikacji klient-serwer. Co więcej, jest on przeznaczony do użytku w skali internetowej, więc połączenie między agentem użytkownika (klientem) a serwerem źródłowym musi być jak najlżejsze (luźne), aby ułatwić adopcję na dużą skalę. Osiąga się to poprzez utworzenie warstwy abstrakcji na serwerze poprzez zdefiniowanie zasobów, które hermetyzują jednostki (np. pliki) na serwerze, a tym samym ukrywanie podstawowych szczegółów implementacji (serwer plików, baza danych itp.). Ale definicja jest jeszcze bardziej ogólna: każda informacja, którą można nazwać, może być zasobem: obrazem, zapytaniem do bazy danych, usługą czasową (np. „dzisiejsza pogoda w Londynie”), a nawet zbiorem innych zasobów. Takie podejście umożliwia największą interoperacyjność między klientami i serwerami w długotrwałym środowisku internetowym, które przekracza granice organizacyjne (zaufania).

Klienci mogą uzyskiwać dostęp do zasobów tylko za pomocą identyfikatorów URI . Innymi słowy, klient żąda zasobu za pomocą URI, a serwer odpowiada reprezentacją zasobu. Reprezentacja zasobu to kolejna ważna koncepcja w REST; aby zapewnić, że odpowiedzi mogą być interpretowane przez jak największą liczbę aplikacji klienckich , reprezentacja zasobu jest przesyłana w formacie hipertekstowym. W ten sposób zasób jest manipulowany poprzez reprezentacje hipertekstowe przesyłane w wiadomościach między klientami a serwerami.

Silne rozdzielenie klienta i serwera wraz z tekstowym przesyłaniem informacji za pomocą jednolitego protokołu adresowania dały podstawę do spełnienia wymagań sieci: odporność (anarchiczna skalowalność), niezależne rozmieszczanie komponentów, transfer danych wielkoziarnistych oraz bariera niskiego wejścia zarówno dla czytelników treści, autorów treści, jak i programistów.

Właściwości architektoniczne

Ograniczenia stylu architektonicznego REST wpływają na następujące właściwości architektoniczne:

  • wydajność w interakcjach między komponentami, która może być dominującym czynnikiem wpływającym na wydajność postrzeganą przez użytkownika i wydajność sieci;
  • skalowalność pozwalająca na obsługę dużej liczby komponentów i interakcji między komponentami;
  • prostota jednolitego interfejsu;
  • możliwość modyfikowania komponentów w celu zaspokojenia zmieniających się potrzeb (nawet podczas działania aplikacji);
  • widoczność komunikacji między komponentami przez agentów serwisowych;
  • przenośność komponentów poprzez przenoszenie kodu programu wraz z danymi;
  • niezawodność w odporności na awarie na poziomie systemu w przypadku awarii komponentów, złączy lub danych.

Ograniczenia architektoniczne

Styl architektoniczny REST definiuje sześć wiązań prowadzących. Gdy te ograniczenia zostaną zastosowane w architekturze systemu, zyskuje on pożądane właściwości niefunkcjonalne , takie jak wydajność, skalowalność, prostota, możliwość modyfikacji, widoczność, przenośność i niezawodność. System, który spełnia niektóre lub wszystkie z tych ograniczeń, jest luźno nazywany RESTful.

Formalne ograniczenia REST są następujące:

Architektura klient-serwer

Zobacz też: Model klient-serwer

Wzorzec projektowy klient-serwer wymusza zasadę separacji obaw : oddzielenie problemów związanych z interfejsem użytkownika od problemów związanych z przechowywaniem danych. W ten sposób poprawiono przenośność interfejsu użytkownika. W przypadku sieci powstało mnóstwo przeglądarek internetowych dla większości platform bez konieczności znajomości jakichkolwiek implementacji serwerowych. Separacja upraszcza również komponenty serwera, poprawiając skalowalność, ale co ważniejsze, pozwala na niezależną ewolucję komponentów (skalowalność anarchiczna), co jest niezbędne w środowisku internetowym obejmującym wiele domen organizacyjnych.

Bezpaństwowość

Zobacz też: Protokół bezstanowy

W informatyce protokół bezstanowy jest protokołem komunikacyjnym, w którym żadne informacje o sesji nie są zachowywane przez odbiorcę, zwykle serwer. Odpowiednie dane sesji są wysyłane do odbiorcy przez klienta w taki sposób, że każdy przesyłany pakiet informacji może być rozumiany oddzielnie, bez informacji kontekstowych z poprzednich pakietów w sesji. Ta właściwość protokołów bezstanowych czyni je idealnymi w aplikacjach o dużej objętości, zwiększając wydajność poprzez usuwanie obciążenia serwera spowodowanego przechowywaniem informacji o sesji.

Pamięć podręczna

Zobacz też: Pamięć podręczna sieci

Podobnie jak w sieci WWW, klienci i pośrednicy mogą buforować odpowiedzi. Odpowiedzi muszą, w sposób dorozumiany lub jawny, określać się jako buforowalne lub niebuforowane, aby uniemożliwić klientom dostarczanie przestarzałych lub nieodpowiednich danych w odpowiedzi na kolejne żądania. Dobrze zarządzane buforowanie częściowo lub całkowicie eliminuje niektóre interakcje klient-serwer, dodatkowo poprawiając skalowalność i wydajność.

System warstwowy

Zobacz także: System warstwowy

Klient zwykle nie może stwierdzić, czy jest połączony bezpośrednio z serwerem końcowym, czy z pośrednikiem po drodze. Jeśli serwer proxy lub system równoważenia obciążenia zostanie umieszczony między klientem a serwerem, nie wpłynie to na ich komunikację i nie będzie potrzeby aktualizowania kodu klienta lub serwera. Serwery pośredniczące mogą poprawić skalowalność systemu , umożliwiając równoważenie obciążenia i udostępniając współdzieloną pamięć podręczną. Ponadto zabezpieczenia można dodać jako warstwę nad usługami sieciowymi, oddzielając logikę biznesową od logiki zabezpieczeń. Dodanie zabezpieczeń jako oddzielnej warstwy wymusza stosowanie zasad bezpieczeństwa . Wreszcie, serwery pośredniczące mogą wywoływać wiele innych serwerów w celu wygenerowania odpowiedzi dla klienta.

Kod na żądanie (opcjonalnie)

Zobacz też: Skrypty po stronie klienta

Serwery mogą tymczasowo rozszerzać lub dostosowywać funkcjonalność klienta, przesyłając kod wykonywalny: na przykład skompilowane komponenty, takie jak aplety Java , lub skrypty po stronie klienta, takie jak JavaScript .

Jednolity interfejs

Ograniczenie jednolitego interfejsu ma fundamentalne znaczenie dla projektowania każdego systemu RESTful. Upraszcza i oddziela architekturę, dzięki czemu każda część rozwija się niezależnie. Cztery ograniczenia dla tego jednolitego interfejsu to:

  • Identyfikacja zasobów w żądaniach — poszczególne zasoby są identyfikowane w żądaniach, na przykład przy użyciu identyfikatorów URI w usługach sieci Web RESTful. Same zasoby są koncepcyjnie oddzielone od reprezentacji zwracanych klientowi. Na przykład serwer może wysyłać dane ze swojej bazy danych jako HTML , XML lub JSON — żaden z nich nie jest wewnętrzną reprezentacją serwera.
  • Manipulowanie zasobami za pomocą reprezentacji — gdy klient przechowuje reprezentację zasobu, w tym wszelkie dołączone metadane , ma wystarczającą ilość informacji, aby zmodyfikować lub usunąć stan zasobu.
  • Wiadomości samoopisowe — każda wiadomość zawiera wystarczającą ilość informacji, aby opisać sposób przetwarzania wiadomości. Na przykład, który parser ma zostać wywołany, może być określony przez typ nośnika .
  • Hipermedia jako silnik stanu aplikacji ( HATEOAS ) — po uzyskaniu dostępu do początkowego identyfikatora URI aplikacji REST — analogicznie do użytkownika sieci Web uzyskującego dostęp do strony głównej witryny — klient REST powinien mieć możliwość dynamicznego korzystania z łączy udostępnionych przez serwer w celu odkryj wszystkie dostępne zasoby, których potrzebuje. W miarę postępu dostępu serwer odpowiada tekstem zawierającym hiperłącza do innych aktualnie dostępnych zasobów. Nie ma potrzeby, aby klient był zakodowany na sztywno z informacjami dotyczącymi struktury lub dynamiki aplikacji.

Modele klasyfikacji

Kilka modeli zostało opracowanych, aby pomóc w klasyfikowaniu interfejsów API REST zgodnie z ich zgodnością z różnymi zasadami projektowania REST, takimi jak Richardson Maturity Model .

Stosowany do usług internetowych

Interfejsy API usług sieci Web, które są zgodne z ograniczeniami architektury REST, są nazywane interfejsami API RESTful. Interfejsy API RESTful oparte na HTTP są zdefiniowane z następującymi aspektami:

  • podstawowy URI , taki jak http://api.example.com/;
  • standardowe metody HTTP (np. GET, POST, PUT i DELETE);
  • a typ nośnika Taki stan przejściowy wyznacza elementy danych (na przykład, atom, mikroformaty aplikacji / vnd.collection + json, etc.). Obecna reprezentacja mówi klientowi, jak komponować żądania przejścia do wszystkich następnych dostępnych stanów aplikacji. Może to być tak proste jak identyfikator URI lub tak złożone jak aplet Javy.

Semantyka metod HTTP

W poniższej tabeli pokazano, w jaki sposób metody HTTP mają być używane w interfejsach API HTTP, w tym RESTful.

Semantyka metod HTTP
Metoda HTTP Opis
DOSTWAĆ Uzyskaj reprezentację stanu zasobu docelowego.
POCZTA Pozwól, aby zasób docelowy przetworzył reprezentację zawartą w żądaniu.
POŁOŻYĆ Utwórz lub zastąp stan zasobu docelowego stanem zdefiniowanym przez reprezentację zawartą w żądaniu.
KASOWAĆ Usuń stan zasobu docelowego.

Metoda GET jest safe , co oznacza, że ​​zastosowanie jej do zasobu nie powoduje zmiany stanu zasobu (semantyka tylko do odczytu). Metody GET, PUT i DELETE są idempotentne , co oznacza, że ​​ich wielokrotne zastosowanie do zasobu powoduje taką samą zmianę stanu zasobu, jak jednokrotne zastosowanie, chociaż odpowiedź może się różnić. Metody GET i POST są buforowane , co oznacza, że ​​odpowiedzi na nie mogą być przechowywane do ponownego wykorzystania w przyszłości.

Dyskusja

W przeciwieństwie do usług internetowych opartych na protokole SOAP , nie ma „oficjalnych” standardów dla internetowych interfejsów API RESTful. Dzieje się tak, ponieważ REST jest stylem architektonicznym, podczas gdy SOAP jest protokołem. REST nie jest sam w sobie standardem, ale implementacje RESTful wykorzystują standardy, takie jak HTTP , URI , JSON i XML . Wielu programistów opisuje swoje interfejsy API jako zgodne z REST, mimo że te interfejsy API nie spełniają wszystkich opisanych powyżej ograniczeń architektonicznych (zwłaszcza ograniczenia jednolitego interfejsu).

Zobacz też

Bibliografia

Dalsza lektura