Przyglądałem się różnym przykładom wykorzystania Springa z REST . Naszym celem końcowym jest HATEOAS/HALkonfiguracja wiosenna
Widziałem dwie różne metody renderowania REST w Spring
Za @RestControllerpośrednictwem kontrolera
Przez @RepositoryRestResourcew repozytorium
Staram się znaleźć, dlaczego miałbyś używać jednego nad drugim. Kiedy próbujesz wdrożyć, HALco jest najlepsze?
Nasza baza danych to Neo4j .
Ok, więc krótka historia jest taka, że chcesz użyć, @RepositoryRestResourceponieważ tworzy to usługę HATEOAS z Spring JPA .
Jak widzisz tutaj dodając tę adnotację i łącząc ją z Twoim Pojo masz w pełni funkcjonalną usługę HATEOAS bez konieczności implementowania metody repozytorium lub metod usługi REST
Jeśli dodasz @RestController, musisz zaimplementować każdą metodę, którą chcesz ujawnić samodzielnie, a także nie eksportuje ona tego do formatu HATEOAS .
Istnieje trzecia (i czwarta) opcja, której nie opisałeś, czyli użycie @BasePathAwareController lub @RepositoryRestController, w zależności od tego, czy wykonujesz akcje specyficzne dla jednostki, czy nie.
@RepositoryRestResource służy do ustawiania opcji w publicznym interfejsie repozytorium - automatycznie utworzy odpowiednie punkty końcowe w oparciu o typ rozszerzanego repozytorium (tj. CrudRepository / PagingAndSortingRepository / etc).
@BasePathAwareController i @RepositoryRestController są używane, gdy chcesz ręcznie tworzyć punkty końcowe, ale chcesz użyć skonfigurowanych konfiguracji Spring Data REST.
Jeśli użyjesz @RestController, utworzysz równoległy zestaw punktów końcowych z różnymi opcjami konfiguracji - np. Inny konwerter komunikatów, różne procedury obsługi błędów itp. - ale szczęśliwie będą współistnieć (i prawdopodobnie spowodują zamieszanie).
Szczegółową dokumentację można znaleźć tutaj .
źródło
@RestControllerużywa tej samej ścieżki co a@RepositoryRestResource, punkty końcowe repozytorium nie zostaną utworzone.Cóż, powyższe odpowiedzi są poprawne w ich kontekście, ale daję ci praktyczny przykład.
W wielu scenariuszach w ramach API musimy zapewnić punkty końcowe do wyszukiwania encji na podstawie określonych kryteriów. Teraz używając JPA nie musisz nawet pisać zapytań, po prostu stwórz interfejs i metody z określoną nomenklaturą Spring-JPA. Aby udostępnić takie interfejsy API, utworzysz warstwę usług, która po prostu wywoła te metody repozytorium, a na końcu kontrolery, które ujawnią punkty końcowe, wywołując warstwę usług.
To, co zrobiła tutaj Spring, pozwoliło na ujawnienie tych punktów końcowych z takich interfejsów (repozytoriów), które są zwykle wywołaniami GET do wyszukiwania encji, aw tle generuje pliki niezbędne do utworzenia końcowych punktów końcowych. Więc jeśli używasz @RepositoryRestResource, nie ma potrzeby tworzenia warstwy usługi / kontrolera.
Z drugiej strony @RestController to kontroler, który zajmuje się konkretnie danymi json i resztą działa jako kontroler. W skrócie @Controller + @ResponseBody = @RestController.
Mam nadzieję że to pomoże.
Zobacz mój przykład roboczy i blog dla tego samego:
http://sv-technical.blogspot.com/2015/11/spring-boot-and-repositoryrestresource.html
https://github.com/svermaji/Spring-boot-with -hibernate-no-controller
źródło
@RepositoryRestControllernadpisuje domyślne generowane kontrolery Spring Data REST z udostępnionego repozytorium.Np. Te kontrolery używają
spring.data.rest.basePathustawienia Spring Boot jako ścieżki bazowej dla routingu.Zobacz Przesłanianie programów obsługi odpowiedzi REST danych Spring .
Pamiętaj o dodawaniu,
@ResponseBodyponieważ jest pomijane w@RepositoryRestControllerJeśli nie ujawniłeś repozytorium (oznaczonego jako
@RepositoryRestResource(exported = false)), użyj@BasePathAwareControllerzamiast tego adnotacjiUważaj również na torby
ControllerLinkBuildernie bierze pod uwagę ścieżki bazowej Spring Data REST i@RequestMappingnie powinien być używany na poziomie klasy / typui
Ścieżka podstawowa nie pojawia się w HAL
Obejście problemu z linkiem: https://stackoverflow.com/a/51736503/548473
AKTUALIZACJA: w końcu wolę nie używać
@RepositoryRestControllerze względu na wiele obejść.źródło