Ktoś używa na co dzień tego w pracy? Lub w swoich projektach?
Jakie są tego zalety oprócz tego, że bardziej oddzielamy klienta od aplikacji/mikroserwisów?
1
0
Zaletą jest to, że frond end starczy, że zna jeden link, a wszystkie kolejne urle odczyta sobie po drodze, przez co łatwiej zmieniać endpointy
0
Też bym chciał wiedzieć. Był u nas na Silesia Jugu kiedyś gościu (znany człowiek) z prezentacją i opisywał, że gdzieś używają pełnego Hatosa. Zapytałem od razu czy to rzeczywiście dużo daje, ale z odpowiedzi wywnioskowałem, że nie za bardzo wiedział. Jak dla mnie - czysta teoria. Ciekawe, czy ktoś się odezwie.
0
Korzystaliśmy z HATEOASa w jednym z projektów - narzucone przez zespół klienta. Problemy na jakie się natknęliśmy to to, że rok temu nie było wiele bibliotek frontowych, które potrafiły bez problemu konsumować takie API (u nas był react ale to robił inny team i jakoś sobie w końcu poradzili). Jeśli używamy spring data rest + hateoas to bardzo fajne budowane są odpowiedzi, przeglądanie resoureów zwracanej encji jest bardzo przyjemne (np. do samego przeklikiwania się przez API) bo połączenia które mają między sobą encje są odwzorowane bezpośrednimi linkami do tych encji. To tak jak byście klikali po katalogach ze zdjęciami "Album -> Zdjęcia[Link1, Link2, Link3] -> Zdjęcie[1] -> Osoby na zdjęciu[Link1, Link2, Link3] -> Osoby[1] -> Znajomi[Link1, Link2, Link3] -> Znajomy[1] i tak można sobie skakać po linkach zwracanych przez API i front nie musi sobie sam budować takich linków, więc możesz sobie dowolnie zmieniać API, oni i tak zawsze używają linków zwróconych przez Ciebie.
Minus - jeśli dochodzi coś customwego do zrobienia to budowanie ręcznie takich linków jest niewygodne. Udostępniają do tego api ale po prostu jest mało przyjemne w użyciu. Chyba że nie używasz Spring Data Rest to i tak sam musisz wszystko budować ale IMO nie warto, chyba że jesteś REST-NAZI.
Nie używaliśmy tam swaggera do dokumentacji, więc nie wiem czy Ci załapie endpointy