Czy REST i HATEOAS to dobra architektura dla usług sieciowych?

Jeśli dobrze rozumiem, REST został sformalizowany przez Roy Fieldinga jako model opisowy architektury sieci. AFAIK Fielding nie twierdził, że REST jest dobry, po prostu opisywał faktyczną architekturę sieci. Sieć już w tym momencie udowodniła, że ​​jest ogromnym sukcesem rozproszonego systemu hipertekstu, więc ten rodzaj potwierdza REST jako udaną architekturę w dziedzinie rozproszonej hipermedii, która jest głównie nawigowana i konsumowana przez ludzi.

Usługi sieciowe REST zostały utworzone przez zastosowanie architektury REST do interfejsów API. Ale czy rzeczywiście istnieje powód, by sądzić, że REST jest pożądaną architekturą dla tej domeny? Mówiąc dokładniej, czy są jakieś dowody na to, że HATEOAS stanowi korzystną zasadę projektowania komunikacji między maszynami?

Obawiam się, że HATEOAS ma sens w przypadku hipermediów, ponieważ istnieje kilka dobrze znanych typów treści (HTML, obrazy, wideo itp.), A klient wie, jak je wykorzystać. Jednak w przypadku interfejsów API typy zawartości są bardzo specyficzne i mogą być konsumowane w znaczący sposób przez klienta tylko wtedy, gdy klient jest specjalnie zaprogramowany do ich używania. Zwrócenie adresu URL klientowi samo w sobie nie powoduje, że klient może korzystać ze wskazanego zasobu.

AFAIK Fielding nie twierdził, że REST jest dobry, po prostu opisywał faktyczną architekturę sieci.

Myślę, że to trochę go zaniża. REST jest przecież wyliczeniem stylu architektonicznego , którego używał Fielding jako główny architekt specyfikacji HTTP / 1.1 .

Ale czy rzeczywiście istnieje powód, by sądzić, że REST jest pożądaną architekturą dla tej domeny? Czy istnieją dowody na to, że HATEOAS to korzystna zasada projektowania komunikacji między maszynami?

"To zależy". HATEOAS jest częścią jednolitego ograniczenia interfejsu REST.

Dzięki zastosowaniu ogólnej zasady inżynierii oprogramowania do interfejsu komponentu ogólna architektura systemu jest uproszczona, a widoczność interakcji poprawiona. Wdrożenia są oddzielone od świadczonych przez nie usług, co zachęca do niezależnej ewolucji. Kompromis polega jednak na tym, że jednolity interfejs obniża wydajność, ponieważ informacje są przesyłane w ustandaryzowanej formie, a nie takiej, która jest specyficzna dla potrzeb aplikacji. Interfejs REST został zaprojektowany w taki sposób, aby był wydajny w przypadku przesyłania dużych danych hipermedialnych, optymalizując go pod kątem typowego przypadku sieci, ale w wyniku czego interfejs nie jest optymalny dla innych form interakcji architektonicznych.

Zastanówmy się przez chwilę, co to znaczy. Gdy mam problem z routerem bezprzewodowym, mogę się z nim komunikować przy użyciu tej samej przeglądarki, której używam do przesyłania odpowiedzi na stos wymiany. W szczególności nie ma znaczenia, jakiej przeglądarki używam ani tego, czy moja przeglądarka ma kilka aktualizacji opóźnionych (lub wyprzedzających) w stosunku do oczekiwań routera. Nie ma znaczenia, że ​​organizacja inżynierska, która napisała przeglądarkę, jest całkowicie niezależna od organizacji, która utworzyła interfejs routera.

To po prostu działa .

To oczywiście nie jest uniwersalne. Fielding w 2008 roku napisał:

Nie oznacza to, że uważam, że każdy powinien projektować własne systemy zgodnie ze stylem architektonicznym REST. REST jest przeznaczony do długotrwałych aplikacji sieciowych, które obejmują wiele organizacji. Jeśli nie widzisz potrzeby ograniczeń, nie używaj ich.

Ograniczenia tworzące styl architektoniczny REST zostały wybrane ze względu na właściwości, które wywołują; jeśli te właściwości nie są cenne w twoim przypadku użycia, powinieneś bezwzględnie rozważyć usunięcie odpowiednich ograniczeń.

Tam, gdzie maszyna do maszyny staje się trudna, to utrata przez człowieka zdolności rozmytego dopasowania do semantyki zapewnionej przez reprezentacje. Klienci mogą sobie poradzić znając tylko rodzaje mediów, ale zwykle człowiek patrzy na sygnały semantyczne, aby uzyskać znaczenie.

schema.org to jedna z części starań, aby stworzyć słownictwo do odczytu maszynowego; agenci maszyny używają klienta do znajdowania wskazówek semantycznych i stosują własne rozumienie znaczenia, aby wybrać właściwe działania do podjęcia.

Ale to praca; musisz zainwestować w opracowanie przyjaznych dla maszyn reprezentacji zasobów oraz zapewnienie, że reprezentacje te będą kompatybilne do przodu i wstecz, aby klienci mogli być rozwijani niezależnie.

Gdy jedna organizacja kontroluje zarówno klienta, jak i serwer, korzyści wynikające z tej niezależności są znacznie mniejsze, w takim przypadku ograniczenie może nie być właściwym wyborem architektonicznym.

Nie, „pełny REST” nie jest taki świetny.

Dowodem na to jest brak ludzi, którzy implementują HATEOS w swoich interfejsach API oraz niekończące się argumenty, za pomocą których czasownik HTTP powinien być użyty dla określonego wywołania.

Ale musisz zrozumieć, dlaczego REST jest tak popularny. Przed jego przyjęciem istniały różne szalone, skomplikowane protokoły, takie jak ebXML i SOAP, obejmujące potwierdzenia, limity czasu, identyfikatory rozmów i stan.

Uruchomienie tych rzeczy i wyjaśnienie ich użytkownikom interfejsu API było trudnym zadaniem. „dlaczego nie zrobię GET z identyfikatorem, który chcę w ciągu zapytania, a ty wyślesz mi dane?” było oczywistym i powszechnym pytaniem.

Następnie drugim problemem był XML, javascript go nie rozumiał, schematy były uciążliwe dla tyłka i kończyłyby się na ogromnych plikach txt, w większości składających się z <MyLongObjectName>. Dlatego ludzie zaczęli używać JSON.

Teraz REST ma w sobie trochę kultu, ale ponieważ zasady są tak niejasne, nie przeszkadza to w uruchomieniu użytecznego API, który jest na tyle prosty, że konsumenci „po prostu go dostają” i używają go bez 6 miesięcy na wejście na pokład proces.

Należy zauważyć, że Roy nie był oryginalnym wynalazcą większości zasad REST, łączy wiele zasad, o których wiadomo, że działają w poprzednich systemach w celu rozwiązania różnych specyficznych problemów. REST jest po prostu naturalnym wnioskiem zastosowania tych zasad w jednej architekturze.

Jeszcze zanim Roy Fielding napisał swoją rozprawę na temat REST , HTTP został już zaprojektowany zgodnie z zasadami, które później stały się znane jako REST. Na zakończenie swojej rozprawy napisał:

Na początku naszych wysiłków w ramach Zespołu ds. Inżynierii Internetowej w celu zdefiniowania istniejącego protokołu przesyłania hipertekstu (HTTP / 1.0) [19] i zaprojektowania rozszerzeń dla nowych standardów HTTP / 1.1 [42] i jednolitych identyfikatorów zasobów (URI) [21 ], Uznałem potrzebę modelu działania sieci WWW. Ten wyidealizowany model interakcji w ramach ogólnej aplikacji internetowej, zwany stylem architektonicznym REST, stał się podstawą nowoczesnej architektury internetowej, dostarczając przewodnich zasad, dzięki którym można zidentyfikować wady istniejącej architektury i rozszerzenia zatwierdzony przed wdrożeniem .

REST i HATEOS dobrze pasują do problemu, do którego zostały zaprojektowane:

REST to skoordynowany zestaw ograniczeń architektonicznych, który próbuje zminimalizować opóźnienia i komunikację sieciową, jednocześnie maksymalizując niezależność i skalowalność implementacji komponentów . Osiąga się to poprzez nałożenie ograniczeń na semantykę złącza, podczas gdy inne style koncentrują się na semantyce komponentów. REST umożliwia buforowanie i ponowne użycie interakcji, dynamiczną substytucyjność komponentów i przetwarzanie działań przez pośredników , tym samym spełniając potrzeby rozproszonego systemu hipermedialnego na skalę internetową.

Należy jednak zauważyć, że Internet i REST niekoniecznie są odpowiednie dla każdego problemu:

Podobnie proponowane rozszerzenia można porównać do REST, aby sprawdzić, czy pasują do architektury; jeśli nie, bardziej efektywne jest przekierowanie tej funkcjonalności do systemu działającego równolegle z bardziej odpowiednim stylem architektonicznym.

Więc jeśli twoje pytanie brzmi „Czy REST i HATEOAS to dobra architektura dla usług sieciowych?” wtedy odpowiedź brzmi: „tak, to dobra architektura dla usług sieciowych”. Problem naprawdę polega na tym, czy wszystkie problemy, które ludzie próbowali rozwiązać, instalując je w ograniczeniach sieciowych, naprawdę powinny to być przede wszystkim usługi sieciowe.

Istnieje wiele interfejsów API, które tak naprawdę nie pasują do REST. Interfejsy API, które nie wymagają skalowalności, którą REST ma rozwiązać, nie są wykorzystywane przez wiele organizacji, które mogą ewoluować niezależnie i nie muszą być długotrwałe; w przypadku tych problemów ograniczenia REST są tylko kaftanem bezpieczeństwa.

Ale czy rzeczywiście istnieje powód, by sądzić, że REST jest pożądaną architekturą dla tej domeny? Mówiąc dokładniej, czy istnieją dowody, że HATEOAS jest korzystną zasadą projektowania komunikacji między maszynami?

Dowodem na to jest sukces sieci w rozwiązywaniu problemów wielu ludzi. REST to architektura hybrydowa, która łączy projekty wielu poprzednich stylów architektonicznych. Wiele domen problemowych nie ma wszystkich wymagań sieci i nie musi przestrzegać wszystkich ograniczeń usługi REST, aby działać dobrze. Dlatego istnieje wiele udanych architektur, które działają dobrze, po prostu stosując niektóre części REST, ale nie inne. HATEOAS i jednolity interfejs, na przykład, są zasadami, które są często pomijane przez interfejsy API, które nie muszą przekraczać granic organizacyjnych i systemów o relatywnie krótkim okresie amortyzacji.

W prezentacji Fieldinga na temat Adobe Experience Manager:

REST NIE jest architekturą!

Reszta to styl architektoniczny, który jest abstrakcją różnych architektur istniejących w Internecie.

REST to kumulacja ograniczeń projektowych w celu wywołania właściwości architektonicznych

REST to modne hasło i każdy chce mieć API RESTful. W rzeczywistości, gdy ludzie mieli do czynienia z ograniczeniami REST, porzucili niektóre z tych ograniczeń, ponieważ nie było potrzeby ani żadnej korzyści, by mogli zastosować wszystkie ograniczenia.

Jak wspomniałeś, HATEOAS przydaje się, gdy klient jest przeglądarką internetową. Gdy klient jest aplikacją mobilną, może nie tak bardzo. Byłaby to dobra praktyka, ale istnieją również koszty związane z zaprojektowaniem takiej aplikacji, do tego stopnia, że ​​na przykład zespół ds. Aplikacji mobilnych i zespół zaplecza zgodziły się porzucić to ograniczenie. I to ma sens, ponieważ oba zespoły nie są tak luźno powiązane, ponieważ pracują dla tej samej firmy.

ODPOCZYNEK w AEM

jeśli chcesz stworzyć usługę, z której korzysta inny serwer, to właściwym wyborem jest xmlrpc. Jeśli chcesz, aby usługa była wykorzystywana przez cienkich klientów lub urządzenia o niskim poborze mocy .. lub nieznanych klientów przez otwarty internet, być może pomyśl o odpoczynku przy użyciu json. Ale pamiętaj, json jest gorszym zapisem do określania ogólnych danych, w porównaniu do xml.