Omówienie REST. Część 1: Co to jest ODPOCZYNEK? W tej części zagłębimy się w sposób, w jaki odbywa się komunikacja między klientem a serwerem. Po drodze będziemy odkrywać nowe terminy i wyjaśniać je. Aby wszystko było jasne, przeanalizujemy komunikację klient-serwer na przykładzie aplikacji RESTful. Załóżmy, że tworzymy aplikację internetową, która przechowuje informacje o klientach i ich zamówieniach. Innymi słowy, nasz system jest w stanie wykonywać operacje na określonych podmiotach: tworzyć je, edytować i usuwać oraz wyświetlać informacje o nich. Tymi podmiotami będą:
klienci (klienci)
zamówienia (zamówienia klientów)
przedmioty (produkty)
W architekturze RESTful klienci wysyłają żądania do serwera w celu pobrania lub modyfikacji danych, a następnie serwery wysyłają klientom odpowiedzi na ich żądania.
Upraszanie
Żądania klientów są prawie zawsze wykonywane przy użyciu protokołu HTTP. Ogólnie żądania HTTP składają się z kilku elementów:
Metoda HTTP
nagłówek
URI
ciało żądania
Poniżej rozważymy każdy komponent bardziej szczegółowo.
Identyfikatory URI i zasoby
Dane, które klienci otrzymują lub modyfikują za pośrednictwem żądań, nazywane są zasobami. Komunikacja klient-serwer polega na manipulowaniu zasobami. W REST zasoby to wszystko, czemu możesz nadać nazwę. W pewnym sensie są jak klasy w Javie. W Javie możemy stworzyć klasę do wszystkiego. Tak więc w REST zasobem może być wszystko: użytkownik, dokument, raport, zamówienie. Może to być abstrakcja jakiejś jednostki lub coś konkretnego, na przykład obraz, wideo, animacja lub plik PDF. W naszym przykładzie mamy 3 zasoby:
klienci (klienci)
zamówienia (zamówienia klientów)
przedmioty (produkty)
Klienci wysyłają żądania do lokalizacji zasobów zwanych punktami końcowymi. Mówiąc prościej, punkt końcowy jest jak adres w sieci. Zanurzając się głębiej, możemy powiedzieć, że punktem końcowym jest URI, czyli ciąg znaków identyfikujący zasób abstrakcyjny lub fizyczny. Jednolity identyfikator zasobów (URI) Czasami punkt końcowy lub URI jest nazywany ścieżką, co oznacza ścieżkę do zasobu. Na potrzeby tego artykułu będziemy używać terminu URI. Każdy określony zasób musi mieć unikalny identyfikator URI. Deweloper serwera jest odpowiedzialny za zapewnienie, że każdy zasób ma zawsze swój własny identyfikator URI. W naszym przykładzie jesteśmy programistami, więc zrobimy to tak, jak wiemy. Tak jak często przypisuje się identyfikatory numeryczne jako klucze podstawowe w relacyjnej bazie danych, każdy zasób ma również swój własny identyfikator w REST. Identyfikator zasobu w REST często odpowiada identyfikatorowi rekordu w bazie danych, w którym przechowywane są informacje o zasobie. REST URI zwykle zaczynają się od liczby mnogiej rzeczownika opisującego jakiś zasób. Na przykład, "
/customers — URI wszystkich dostępnych klientów
/customers/23 — URI konkretnego klienta, czyli klienta o ID=23
/customers/4 — URI konkretnego klienta, czyli klienta o ID=4.
Ale to nie wszystko. Możemy rozszerzyć URI dodając zamówienia:
/customers/4/orders — URI wszystkich zamówień złożonych przez klienta nr 4
/customers/1/orders/12 — URI zamówienia nr 12 złożonego przez klienta nr 1.
Jeśli będziemy kontynuować rozbudowę dodając kolejne produkty, otrzymamy:
/customers/1/orders/12/items — URI listy wszystkich produktów w zamówieniu nr 12 złożonym przez klienta nr 1.
Ponieważ dodajemy poziomy zagnieżdżania, ważne jest, aby identyfikatory URI były intuicyjne.
Metoda HTTP
Metoda HTTP to ciąg dowolnych znaków (z wyjątkiem znaków sterujących i ograniczników), który wskazuje główną operację wykonywaną na zasobie. Istnieje kilka typowych metod HTTP. Wymienimy te, które są najczęściej używane w usługach RESTful:
GET — Uzyskaj informacje o konkretnym zasobie (poprzez jego identyfikator) lub o zbiorze zasobów
POST — Utwórz nowy zasób
PUT — Zmień zasób (poprzez jego identyfikator)
USUŃ — Usuń zasób (poprzez jego identyfikator)
Nagłówki
Żądania, podobnie jak odpowiedzi, zawierają nagłówki HTTP. Przekazują dodatkowe informacje o żądaniu (lub odpowiedzi). Nagłówki to pary klucz-wartość. Możesz zobaczyć listę najpopularniejszych nagłówków w Wikipedii . Jeśli chodzi o REST, klienci często wysyłają nagłówek „Accept” w żądaniach do serwera. Ten nagłówek jest potrzebny, aby poinformować serwer, w jakim formacie klient oczekuje odpowiedzi. Na liście typów MIME podano różne formaty. MIME (Multipurpose Internet Mail Extensions) to specyfikacja służąca do kodowania informacji i formatowania wiadomości, aby mogły być wysyłane przez Internet. Każdy typ MIME składa się z dwóch części oddzielonych ukośnikiem — typu i podtypu. Przykłady typów MIME dla różnych typów plików:
Ten nagłówek informuje serwer, że klient oczekuje odpowiedzi w formacie JSON.
Prośba o treść
Jest to wiadomość wysyłana przez klienta do serwera. To, czy żądanie ma treść, zależy od typu żądania HTTP. Na przykład żądania GET i DELETE generalnie nie zawierają treści żądania. Ale żądania PUT i POST mogą — zależy to tylko od celu żądania. W końcu, aby odbierać i/lub usuwać dane za pomocą identyfikatora (który jest przekazywany w adresie URL), nie trzeba przesyłać dodatkowych danych na serwer. Ale aby utworzyć nowy zasób (poprzez żądanie POST), musisz wysłać zasób. To samo dotyczy modyfikowania istniejącego zasobu. W REST treść żądania jest najczęściej wysyłana w formacie XML lub JSON. Najpopularniejszy jest format JSON. Załóżmy, że chcemy wysłać żądanie do serwera w celu utworzenia nowego zasobu. Jeśli nie zapomniałeś, rozważaliśmy przykład aplikacji zarządzającej zamówieniami klientów. Powiedzmy, że chcemy stworzyć nowego klienta. W naszym przypadku przechowujemy następujące informacje o kliencie: imię i nazwisko, adres e-mail, numer telefonu. Wtedy treść żądania może być następującym JSON:
Edytuj klienta nr 1 w następujący sposób:
Imię — Ben
E-mail — bigben@jr.com
Numer telefonu — +86 (868) 686-8686
DELETE /customers/12/orders/6
Usuń zamówienie nr 6 złożone przez klienta nr 12 z systemu
Odpowiedzi
Powiedzmy kilka słów o odpowiedziach serwera. Odpowiedź zazwyczaj składa się z następujących części:
kod odpowiedzi
nagłówki
ciało odpowiedzi
Ogólnie rzecz biorąc, nagłówki odpowiedzi niewiele różnią się od nagłówków żądań. Ponadto niektóre nagłówki są używane zarówno w odpowiedziach, jak i żądaniach. Myślę, że wszystko jest również jasne, jeśli chodzi o treść żądania. Organ często zwraca informacje, o które prosi klient. Informacje zwracane w odpowiedzi na żądania GET mogą być również w formacie JSON. Ale ostatnia część jest nieco ciekawsza.
Kody odpowiedzi HTTP
Przyjrzyjmy się bardziej szczegółowo kodom odpowiedzi HTTP. Kod stanu HTTP jest częścią pierwszego wiersza odpowiedzi serwera na żądania wysyłane za pośrednictwem protokołu HTTP. Jest to liczba całkowita składająca się z trzech cyfr dziesiętnych. Pierwsza cyfra wskazuje klasę kodu statusu odpowiedzi. Po kodzie odpowiedzi zwykle następuje zdanie wyjaśniające w języku angielskim, oddzielone spacją. To zdanie jest zrozumiałym dla człowieka powodem odpowiedzi. Przykłady:
201 Stworzony
401 Nieautoryzowane
507 Niewystarczająca pamięć
Kod odpowiedzi informuje klienta o wyniku żądania i pozwala mu określić, jakie działania należy podjąć w następnej kolejności. Kody odpowiedzi są podzielone na kilka klas lub grup:
1XX — Informacyjny
2XX — Te kody wskazują, że żądanie klienta zostało pomyślnie odebrane i przetworzone
3XX — te kody informują klienta, że w celu pomyślnego zakończenia operacji należy złożyć dodatkowe żądanie, zwykle do innego identyfikatora URI
4XX — Błąd klienta. Takie kody mogą wynikać z nieprawidłowo skomponowanego żądania. Innym przykładem jest dobrze znany kod „404 Not Found”, który może wystąpić, gdy klient zażąda nieistniejącego zasobu
5XX — Błąd serwera. Kody te są zwracane klientowi, jeśli serwer jest odpowiedzialny za niepowodzenie operacji
Aby wszystko było jasne, przeanalizujemy komunikację klient-serwer na przykładzie aplikacji RESTful. Załóżmy, że tworzymy aplikację internetową, która przechowuje informacje o klientach i ich zamówieniach. Innymi słowy, nasz system jest w stanie wykonywać operacje na określonych podmiotach: tworzyć je, edytować i usuwać oraz wyświetlać informacje o nich. Tymi podmiotami będą:
