Pytanie Jak przydatne / ważne jest HESTEOAS REST (poziom 3 dojrzałości)?


Angażuję się w projekt, w którym niektórzy starsi członkowie zespołu uważają, że REST API musi być HATEOAS zgodny i wdrażać wszystkie poziomy dojrzałości Richardsona (http://martinfowler.com/articles/richardsonMaturityModel.html)!

Większość wdrożeń REST AFAIK nie jest zgodna z HATEOAS i powinien istnieć dobry powód, dla którego więcej osób tego nie robi. Mogę wymyślić powody takie jak złożoność, brak ram (strona serwera i klienta), obawy dotyczące wydajności i ...

Co myślisz? Czy miałeś już jakieś doświadczenie z HATEOAS w prawdziwym świecie?


76
2017-12-02 19:11


pochodzenie




Odpowiedzi:


Nikt w społeczności REST nie twierdzi, że REST jest łatwe. HATEOAS to tylko jeden z aspektów, który dodaje trudności architekturze REST.

Ludzie nie robią HATEOAS ze wszystkich powodów, które sugerujesz: jest to trudne. Zwiększa złożoność zarówno po stronie serwera, jak i klienta (jeśli rzeczywiście chcesz z niego skorzystać).

JEDNAK, miliardy ludzi doświadczają dziś korzyści z REST. Czy wiesz, jaki jest adres URL "kasy" w Amazon? Ja nie. Mogę jednak kasować każdego dnia. Czy ten URL został zmieniony? Nie wiem, nie obchodzi mnie to.

Czy wiesz, że się opiekujesz? Każdy, kto napisał ekran, zdrapywał zautomatyzowanego klienta Amazon. Ktoś, kto najprawdopodobniej starannie powąchał ruch sieciowy, przeczytał strony HTML itp., Aby znaleźć linki do połączenia, kiedy i przy użyciu ładunków.

Gdy tylko Amazon zmienił swoje wewnętrzne procesy i strukturę adresów URL, ci nie zakodowani klienci się nie powiodło - ponieważ łącza się zepsuły.

Jednak zwykli internauci byli w stanie robić zakupy przez cały dzień bez większego problemu.

To jest REST w akcji, jest po prostu powiększany przez człowieka, który potrafi interpretować i intuicyjnie korzystać z interfejsu tekstowego, rozpoznawać małą grafikę z koszykiem na zakupy i zastanawiać się, co to właściwie oznacza.

Większość ludzi piszących oprogramowanie tego nie robi. Większość ludzi piszących zautomatyzowanych klientów nie dba o to. Większość ludzi łatwiej naprawia swoich klientów, gdy się łamią, niż inżynier aplikacji, aby nie złamać się na pierwszym miejscu. Większość ludzi po prostu nie ma wystarczającej liczby klientów, gdzie to ma znaczenie.

Jeśli piszesz wewnętrzny interfejs API, aby komunikować się między dwoma systemami z zaawansowanym wsparciem technicznym i IT po obu stronach ruchu, którzy są w stanie komunikować zmiany szybko, niezawodnie iz harmonogramem zmian, wtedy REST nie kupi ci nic. Nie potrzebujesz tego, twoja aplikacja nie jest wystarczająco duża i nie jest wystarczająco długa, by się liczyła.

Duże witryny z dużymi użytkownikami mają ten problem. Nie mogą po prostu poprosić ludzi, aby zmienili kod klienta podczas kaprysu podczas interakcji z ich systemami. Harmonogram rozwoju serwerów nie jest taki sam, jak harmonogram rozwoju klienta. Nagłe zmiany w API są po prostu niedopuszczalne dla wszystkich zaangażowanych, ponieważ zakłócają ruch i operacje po obu stronach.

Taka operacja prawdopodobnie skorzystałaby z HATEOAS, ponieważ jest łatwiejsza w wersji, łatwiejsza jest migracja starszych klientów, łatwiejsza do uzyskania zgodności wstecznej niż nie.

Klient delegujący znaczną część swojej pracy do serwera i działający na wyniki jest znacznie bardziej odporny na zmiany serwera niż klient, który tego nie robi.

Ale większość ludzi nie potrzebuje takiej elastyczności. Piszą kod serwera dla 2 lub 3 działów, to wszystko jest do użytku wewnętrznego. Jeśli się zepsuje, naprawią to i uwzględnią to w swoich normalnych działaniach.

Elastyczność, czy to z REST, czy cokolwiek innego, rodzi złożoność. Jeśli chcesz, aby był prosty i szybki, nie czynisz go elastycznym, po prostu "robisz to" i musisz to zrobić. Kiedy dodajesz abstrakcje i dereferencje do systemów, wtedy rzeczy stają się trudniejsze, więcej płyty kotła, więcej kodu do przetestowania.

Znaczna część REST kończy się błędem "nie potrzebujesz tego". Aż, oczywiście, robisz.

Jeśli jej potrzebujesz, użyj go i używaj, tak jak jest ułożona. REST nie przesuwa rzeczy tam iz powrotem przez HTTP. Nigdy nie było, jest to znacznie wyższy poziom.

Ale kiedy potrzebujesz REST i używasz REST, wtedy HATEOAS jest koniecznością. Jest to część pakietu i klucz do tego, co w ogóle działa.


148
2017-12-02 19:31



Czuję, że powinieneś mieć co najmniej tysiąc więcej polubień dla tej odpowiedzi. Szczerze mówiąc, muszę sobie wyobrazić: jak ważne jest "prawdziwe" pytanie REST pojawia się całkiem sporo. Do licha, robiłem trochę googlowania z tego powodu amunicji do wykorzystania podczas najbliższego spotkania, kiedy znalazłem ten wątek. - nograde
tysiąc lubi ++ - felipecao
dzięki Bogu (lub kodowi), ktoś mówi również o wadach HATEOAS! - IlliakaillI
Czy jest jakaś inna zaleta, to możliwość łatwej zmiany adresów URL? Nie można po prostu dodawać nowych opcji, ponieważ w przeciwieństwie do ludzi program nie może działać z czymś nowym. Poza tym przesunąłeś się tylko od budowania znanych adresów URL do znajomości nazw akcji. - Jimmy T.
Jeśli konsument API nic nie wie, może delegować tylko akcje użytkownika 1: 1 - Jimmy T.


Tak, miałem pewne doświadczenie z hipermediami w API. Oto niektóre z korzyści:

  1. Explorable API: To może wydawać się banalne, ale nie lekceważ potęgi eksplodującego interfejsu API. Możliwość przeglądania danych ułatwia programistom klienta budowanie modelu mentalnego API i jego struktur danych.

  2. Dokumentacja wewnętrzna: Używanie adresów URL jako relacji między linkami może wskazywać programistom klienta dokumentację.

  3. Prosta logika klienta: Klient, który po prostu podąża za adresami URL zamiast tworzyć je sam, powinien być łatwiejszy w implementacji i utrzymaniu.

  4. Serwer przejmuje na własność struktury adresów URL: Korzystanie z hipermediów powoduje usunięcie zakodowanej przez klienta wiedzy o strukturach URL używanych przez serwer.

  5. Wyłącz ładowanie treści do innych usług: Hypermedia jest niezbędna przy ładowaniu treści do innych serwerów (na przykład CDN).

  6. Wersja z linkami: Hypermedia pomaga w wersjonowaniu interfejsów API.

  7. Wiele implementacji tej samej usługi: Hypermedia jest koniecznością, gdy istnieje wiele implementacji tej samej usługi (i jeden klient musi uzyskać dostęp do więcej niż jednego z nich).

Tutaj znajdziesz szczegółowe wyjaśnienie tych punktów: http://soabits.blogspot.no/2013/12/selling-benefits-of-hypermedia.html

(istnieje podobne pytanie tutaj: https://softwareengineering.stackexchange.com/questions/149124/what-is-the-benefit-of-hypermedia-hateoas gdzie dałem to samo wyjaśnienie)


14
2017-12-11 09:04





Myślę, że API można nazwać RESTful, nawet jeśli strona klienta nie jest zgodna z zasadami HATEOAS. W większości przypadków klient musi naruszają HATEOAS w celu spełnienia wymagań użyteczności. Pozwól mi wyjaśnić.

HATEOAS nie tylko nakłada ograniczenia po stronie serwera aplikacji, ale także po stronie klienta. Klient nie powinien zakładać, że zasób ma określoną strukturę wykraczającą poza strukturę zdefiniowaną przez typ nośnika. Serwer powinien oferować interfejs API obsługujący takiego klienta.

Teraz załóżmy, że to osiągnęliśmy. Strona aplikacji po stronie klienta jest teraz bardzo ogólna, ale najprawdopodobniej wrażenia użytkownika są złe, ponieważ bez znajomości semantyki zasobów prezentacja zasobów nie może być dostosowana do odzwierciedlenia tej semantyki. Jeśli zasób "samochód" i "dom" zasobów mają ten sam typ mediów (np. Aplikacja / json), zostaną one przedstawione użytkownikowi w ten sam sposób, na przykład jako tabela właściwości (pary nazwa / wartość).

Ale w porządku, nasze API jest naprawdę UTRZYMUJĄCE SIĘ.

Załóżmy teraz, że tworzymy drugą aplikację kliencką na szczycie tego API. Ten drugi klient narusza pomysły HATEOAS i ma zakodowane informacje o zasobach. Wyświetla samochód i dom na różne sposoby.

Czy API może nadal być nazywane RESTful? Chyba tak. To nie jest wina API, że jeden z jej klientów naruszył HATEOAS.

Radzę tworzyć RESTful APIs, czyli API, dla których można wdrożyć klienta ogólnego W teorii, ale w większości przypadków potrzebujesz trochę zakodowane informacje o zasobach w twoim kliencie w celu spełnienia wymagań. Mimo to, staraj się jak najtrudniej kodować, aby zmniejszyć zależności między klientem a serwerem.

Zawarłem sekcję o HATEOAS w moim wzorze wdrożenia REST nazwany JAREST.


5
2017-10-24 16:14





Użyłem HATEOAS w niektórych prawdziwych projektach, ale z inną interpretacją niż Richardson. Jeśli tego chcą twoi szefowie, to powinieneś po prostu to zrobić. Biorę HATEOAS oznacza, że ​​twoje zasoby powinny zawierać dokument w formacie HTML, hiperłącza do powiązanych zasobów i formularzy HTML, aby eksponować funkcjonalność dla czasowników innych niż GET. (To jest, gdy typem Accept jest text / html - inne typy zawartości nie wymagają tych dodatków.) Nie wiem, skąd pochodzi przekonanie, że wszystkie zasoby REST w całej aplikacji muszą być sklejone. Aplikacja sieciowa powinna zawierać wiele zasobów, które mogą być lub mogą nie być bezpośrednio powiązane. Lub dlaczego uważa się, że XML, JSON i inne typy muszą przestrzegać tego. (HATEOAS jest specyficzny dla HTML.)


2
2017-12-02 20:38