8.1 Podejście do zdalnego API
Wszyscy programiści popełniają ten sam błąd budując architekturę klient-serwer. Zaczynają traktować żądania do serwera jako wywołania metod .
Chcesz rozpocząć proces generowania raportu na serwerze, dlaczego nie wysłać do niego żądania typu:
http://server.com/startDocumentGeneration?paramsA jak pobrać raport po jego zakończeniu? Aby to zrobić, napiszemy inną metodę:
http://server.com/getDocumentSerwer przechowuje HttpSessioninformacje o naszym dokumencie, a gdy tylko dokument zostanie wygenerowany, serwer go zwróci.
Świetne podejście. Albo nie?
Podejście jest naprawdę straszne. Rzecz w tym, że serwer musi zapamiętać numer dokumentu. Innymi słowy, aby poprawnie przetworzyć wywołania nowych metod, serwer musi zapamiętać wyniki wywołań poprzednich metod.
W sieci jest to duży problem. Internet może zniknąć, przeglądarka może się zamknąć. Strona może zostać ponownie załadowana lub przypadkowo kliknięta w link i tak dalej. A serwer będzie nadal przechowywać megabajty danych z poprzednich żądań użytkowników ...
Dla komfortowej pracy z serwerem nie możesz oczekiwać, że zawsze będziesz mieć pod ręką dane poprzednich zapytań do serwera.
Jak zatem wywoływać metody serwera? Prawidłowa odpowiedź byłaby okropna: nie ma mowy!
8.2 Podejście REST
Programiści wrócili do podstaw i przypomnieli sobie, że początkowo żądanie zawierało ścieżkę do pliku na serwerze:
http://server.com/path?paramsI postanowiliśmy maksymalnie wykorzystać to podejście.
Teraz serwer jest traktowany jako repozytorium danych , które są widoczne na zewnątrz w postaci drzewa .
Jeśli chcesz uzyskać listę wszystkich użytkowników, wywołaj zapytanie:
http://server.com/usersJeśli chcesz uzyskać dane o użytkowniku 113, uruchom zapytanie:
http://server.com/users/113I tak dalej, wszystko w tym samym duchu.
Po raz kolejny serwer jest postrzegany jako repozytorium danych, które są widoczne na zewnątrz w postaci drzewa.
Dane mogą być odbierane - żądania GET , modyfikowane - żądanie POST oraz usuwane - żądanie DELETE .
8.3 Brak stanu
Protokół REST interakcji między klientem a serwerem wymaga spełnienia następującego warunku: w okresie między żądaniami od klienta na serwerze nie są przechowywane żadne informacje o stanie klienta.
Wszystkie żądania od klienta muszą być przygotowane w taki sposób, aby serwer za każdym razem otrzymał wszystkie informacje potrzebne do zrealizowania żądania . Stan sesji jest zapisywany po stronie klienta.
Podczas przetwarzania żądań klientów uważa się, że klient znajduje się w stanie przejściowym. Każdy indywidualny stan aplikacji jest reprezentowany przez łącza, które można wywołać przy następnym uruchomieniu klienta.
8.4 Jednorodność interfejsu
Wszystkie ścieżki używane do pobierania obiektów z serwera są ustandaryzowane. Jest to bardzo wygodne, zwłaszcza jeśli pobierasz dane z innych serwerów REST.
Wszystkie interfejsy obiektów muszą spełniać trzy warunki:
Identyfikacja zasobów
Wszystkie zasoby są identyfikowane w żądaniach za pomocą identyfikatora URI. Zasoby wewnątrz serwera są oddzielone od widoków zwracanych klientom. Na przykład serwer może wysyłać dane z bazy danych w formacie HTML, XML lub JSON, z których żaden nie jest typem przechowywania na serwerze.
Manipulowanie zasobami za pomocą widoku
Jeśli klient przechowuje reprezentację zasobu, w tym metadane, ma wystarczającą ilość informacji, aby zmodyfikować lub usunąć zasób na serwerze.
Komunikaty „samoopisujące się”.
Każda wiadomość zawiera wystarczającą ilość informacji, aby zrozumieć, jak sobie z nią poradzić. Na przykład, jeśli potrzebujesz informacji o użytkowniku, serwer zwróci ci obiekt JSON, w którym będą pola nazwa, adres.
Nie powinno dojść do sytuacji, w której klient musi wiedzieć, że pierwsza cyfra w odpowiedzi to wiek, a druga to data urodzenia.
8.5 Buforowanie
Podejście REST zakłada, że żądania danych realizowane są za pośrednictwem protokołu HTTP. Dlatego obiekty są uzyskiwane przez wywołanie żądania GET. Oznacza to, że podobnie jak wszystkie zasoby otrzymane za pomocą żądania GET podlegają wszystkim regułom dotyczącym buforowania zasobów HTTP.
Oznacza to, że dane otrzymane za pośrednictwem interfejsu API REST są buforowane w taki sam sposób, jak wszelkie zasoby statyczne na serwerach WWW. Uroda :)