Część 1: Czym jest REST W tej części przyjrzymy się bliżej sposobowi komunikacji pomiędzy klientem a serwerem. Po drodze będziemy odkrywać nowe terminy i wyjaśniać je. Aby wszystko (stało się) jasne przeanalizujemy komunikację klient-serwer na przykładzie jakiejś aplikacji RESTful. Załóżmy, że tworzymy aplikację internetową, która może przechowywać informacje o klientach i ich zamówieniach. Te. nasz system potrafi manipulować niektórymi bytami: tworzyć je, edytować, usuwać i dostarczać o nich informacji. Podmiotami tymi będą:
klienci - klienci;
zamówienia – zamówienia klientów;
przedmioty - towary.
W architekturze REST klienci wysyłają żądania do serwera w celu uzyskania lub modyfikacji danych, a serwery wysyłają do klientów odpowiedzi na ich żądania.
Upraszanie
Żądania klientów są prawie zawsze wysyłane za pośrednictwem protokołu HTTP. Ogólnie żądania HTTP składają się z kilku elementów:
metoda HTTP;
tytuł;
URI;
treść żądania.
Poniżej przyjrzymy się bardziej szczegółowo każdej części składowej.
URI i zasoby
Dane, które klienci uzyskują lub modyfikują za pomocą żądań, nazywane są zasobami. Podstawą interakcji klient-serwer jest manipulacja zasobami. Zasoby w REST to wszystko, czemu można nadać nazwę. W pewnym sensie są to klasy w Javie. W Javie możemy stworzyć klasę do wszystkiego. Podobnie jest w REST – zasobem może być wszystko: użytkownik, dokument, raport, zamówienie. Wszystko to może być albo abstrakcją jakiejś istoty, albo czymś konkretnym, na przykład plikiem - zdjęciem, wideo, animacją, plikiem PDF. W naszym przykładzie mamy 3 zasoby:
klienci - klienci;
zamówienia – zamówienia klientów;
przedmioty - towary.
Klienci wysyłają żądania do tak zwanych punktów końcowych lub punktów końcowych. Mówiąc najprościej, punkt końcowy to coś w rodzaju adresu w sieci. Mówiąc głębiej, punktem końcowym jest URI : sekwencja znaków identyfikująca zasób abstrakcyjny lub fizyczny. Uniform Resource Identifier - ujednolicony identyfikator zasobu. Czasami punkt końcowy, czyli URI, nazywany jest ścieżką – ścieżką do zasobu. Na potrzeby tego artykułu będziemy używać terminu URI. Każdy konkretny zasób musi mieć unikalny identyfikator URI. Odpowiedzialność za zapewnienie, że każdy zasób zawsze ma swój własny URI, spoczywa na barkach programisty serwera. W naszym przykładzie jesteśmy programistami, więc zrobimy to tak, jak wiemy. Podobnie jak w relacyjnej bazie danych często zwyczajowo przypisuje się kluczowi podstawowemu określony identyfikator liczbowy, tak w REST każdy zasób ma swój własny identyfikator. Często zdarza się, że identyfikator zasobu w REST jest zgodny z identyfikatorem rekordu w bazie danych, w której przechowywane są informacje o tym zasobie. Identyfikatory URI REST zwykle zaczynają się od liczby mnogiej rzeczownika opisującego jakiś zasób. Na przykład od słowa klienci. Następnie poprzez ukośnik wskazywany jest identyfikator – identyfikator konkretnego klienta. Przykłady:
/clients - URI wszystkich istniejących klientów;
/clients/23 - URI konkretnego klienta, czyli klienta o ID=23;
/clients/4 - URI konkretnego klienta, czyli klienta o ID=4.
Ale to nie wszystko. Możemy rozszerzyć URI dodając do niego zamówienia:
/clients/4/orders — URI wszystkich zamówień klienta nr 4;
/clients/1/orders/12 - URI zamówienia nr 12 klienta nr 1.
Jeśli będziemy kontynuować ten łańcuch i dodamy towary, otrzymamy:
/clients/1/orders/12/items — URI listy wszystkich produktów w zamówieniu nr 12 sporządzonym przez klienta nr 1.
W przypadku poziomów zagnieżdżenia kluczem jest sprawienie, aby identyfikatory URI były intuicyjne.
Metoda HTTP
Metoda HTTP (angielski sposób HTTP) to ciąg dowolnych znaków, z wyjątkiem kontrolek i separatorów, który wskazuje główną operację na zasobie. Istnieje kilka typowych metod HTTP. Wymieniamy te, które są najczęściej używane w usługach RESTful:
GET - służy do uzyskania informacji o konkretnym zasobie (poprzez ID) lub zbiorze zasobów;
POST - używany do utworzenia nowego zasobu;
PUT - służy do zmiany zasobu (poprzez ID);
DELETE - służy do usuwania zasobu (poprzez ID).
Nagłówki
Żądania i odpowiedzi zawierają nagłówki HTTP. Wysyłają dodatkowe informacje na temat żądania (lub odpowiedzi). Nagłówki to pary klucz-wartość. Listę najpopularniejszych nagłówków możesz przeczytać na stronie Wikipedii . Dzięki REST klienci często mogą wysyłać nagłówek Accept w swoim żądaniu do serwera. Konieczne jest poinformowanie serwera, w jakim formacie klient spodziewa się otrzymać od niego odpowiedź. Różne opcje formatu prezentowane są na tak zwanej liście typów MIME. MIME (Multicel Internet Mail Extensions) to specyfikacja kodowania informacji i formatowania wiadomości w celu umożliwienia ich przesyłania 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.
Treść żądania
Wiadomość wysłana przez klienta do serwera. To, czy żądanie ma treść, czy nie, zależy od typu żądania HTTP. Na przykład żądania GET i DELETE zazwyczaj nie zawierają żadnej treści żądania. Ale PUT i POST mogą zawierać: wszystko zależy od funkcjonalnego celu typu żądania. Przecież aby odebrać dane i usunąć je po identyfikatorze (który jest przekazywany w adresie URL), nie trzeba wysyłać dodatkowych danych na serwer. Aby jednak utworzyć nowy zasób (żądanie POST), musisz przenieść ten zasób. To samo dotyczy modyfikacji istniejącego zasobu. W formacie REST do przesyłania treści żądania najczęściej używane są formaty XML lub JSON. Najpopularniejszym formatem jest JSON. Załóżmy, że chcemy wysłać żądanie do serwera i utworzyć w nim nowy zasób. Jeśli pamiętasz, jako przykład spojrzeliśmy na aplikację zarządzającą zamówieniami klientów. Załóżmy, że chcemy stworzyć nowego klienta. W naszym przypadku przechowujemy następujące informacje o klientach: Imię E-mail Numer telefonu Wtedy treścią takiego żądania może być następujący JSON:
Edytuj klienta nr 1 w następujący sposób:
Imię - Ben
E-mail - bigben@jr.com
Tel. — +380 (190) 346-42-13
DELETE /clients/12/orders/6
Usuń z systemu zamówienie nr 6 od klienta nr 12
Odpowiedzi
Powiedzmy kilka słów o odpowiedziach serwera. Odpowiedź zwykle składa się z następujących części:
kod odpowiedzi;
nagłówki;
treść odpowiedzi.
Ogólnie rzecz biorąc, nagłówki odpowiedzi nie różnią się zbytnio 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 jasne, jeśli chodzi o treść odpowiedzi. Organ często zwraca informacje, o które prosił klient. Informacje mogą być zwracane w tym samym formacie JSON dla żądań GET. Ale ostatnia część jest nieco ciekawsza.
Kody odpowiedzi HTTP
Przyjrzyjmy się bliżej kodom odpowiedzi HTTP. Oto cytat z Wikipedii: Kod stanu HTTP jest częścią pierwszej linii odpowiedzi serwera na żądania za pośrednictwem protokołu HTTP. Jest to liczba całkowita zawierająca trzy cyfry po przecinku. Pierwsza cyfra wskazuje klasę warunku. Po kodzie odpowiedzi zwykle następuje zdanie objaśniające w języku angielskim oddzielone spacją, które wyjaśnia osobie powód tej konkretnej odpowiedzi. Przykłady:
201 Utworzono;
401 Nieautoryzowane;
507 Niewystarczająca pamięć.
Klient dowiaduje się z kodu odpowiedzi o wynikach swojego żądania i określa, jakie działania podjąć dalej. Kody odpowiedzi podzielone są na kilka grup:
1ХХ - informacyjny;
2ХХ - informować o przypadkach pozytywnego przyjęcia i rozpatrzenia wniosku klienta;
3XX - poinformuj klienta, że w celu pomyślnego zakończenia operacji konieczne jest złożenie kolejnego żądania, najczęściej z wykorzystaniem innego URI;
4ХХ - błąd klienta. Na przykład niepoprawnie skonstruowane żądanie lub dobrze znany kod 404 Not Found, który może wystąpić, gdy klient zażąda nieistniejącego zasobu;
5ХХ - błąd serwera. Zwracany do klienta, jeśli operacja nie powiedzie się z powodu awarii serwera.
GO TO FULL VERSION