Я розглядав різні приклади того, як використовувати Spring разом з REST . Наша кінцева мета - HATEOAS/HALналаштування Весни
Я бачив два різні методи рендерингу REST протягом весни
Через @RestControllerвсередині контролера
Через @RepositoryRestResourceвсередині сховища
Річ, яку я намагаюся знайти, - чому б ви використовували одне над іншим. При спробі реалізувати, HALщо найкраще?
Наша серверна база даних - Neo4j .
Відповіді:
Гаразд, отже, коротка історія полягає в тому, що ви хочете використовувати, @RepositoryRestResourceоскільки це створює службу HATEOAS із Spring JPA .
Як ви можете бачити тут, додаючи цю анотацію та пов'язуючи її з вашим Pojo, у вас є повністю функціональна служба HATEOAS без необхідності реалізовувати метод сховища або методи REST
Якщо ви додасте, @RestControllerтоді вам доведеться реалізовувати кожен метод, який ви хочете виставити самостійно, а також він не експортує його у формат HATEOAS .
Існує третій (і четвертий) варіант, який ви не окреслили, а саме використання @BasePathAwareController або @RepositoryRestController, залежно від того, виконуєте ви конкретні дії для сутності чи ні.
@RepositoryRestResource використовується для встановлення параметрів на загальнодоступному інтерфейсі сховища - він автоматично створюватиме кінцеві точки відповідно до типу сховища, яке розширюється (тобто CrudRepository / PagingAndSortingRepository / тощо).
@BasePathAwareController і @RepositoryRestController використовуються, коли ви хочете вручну створити кінцеві точки, але хочете використовувати конфігурації Spring Data REST, які ви встановили.
Якщо ви використовуєте @RestController, ви створите паралельний набір кінцевих точок з різними параметрами конфігурації - тобто іншим перетворювачем повідомлень, різними обробниками помилок тощо - але вони будуть радісно співіснувати (і, можливо, спричиняти плутанину).
Конкретну документацію можна знайти тут .
@RestControllerвикористовує той самий шлях, що і a @RepositoryRestResource, кінцеві точки сховища не створюватимуться.
Ну, наведені вище відповіді є правильними у своєму контексті, і все-таки я даю вам практичний приклад.
У багатьох сценаріях як частина API нам потрібно надати кінцеві точки для пошуку сутності на основі певних критеріїв. Тепер, використовуючи JPA, вам не потрібно навіть писати запити, просто створіть інтерфейс та методи з конкретною номенклатурою Spring-JPA. Щоб виставити такі API, ви створите сервісний рівень, який просто викликає ці методи репозиторію і, нарешті, контролери, які виставлять кінцеві точки, викликаючи сервісний рівень.
Те, що тут зробив Spring, дозволяє вам виставити ці кінцеві точки з таких інтерфейсів (сховищ), які зазвичай є викликами GET для пошуку сутності, а у фоновому режимі генерує необхідні файли для створення кінцевих точок. Отже, якщо ви використовуєте @RepositoryRestResource, тоді немає необхідності робити шар Service / Controller.
З іншого боку, @RestController - це контролер, який спеціально має справу з json-даними, а інша робота в якості контролера. Коротше @Controller + @ResponseBody = @RestController.
Сподіваюся, це допомагає.
Дивіться мій робочий приклад і блог для того ж:
http://sv-technical.blogspot.com/2015/11/spring-boot-and-repositoryrestresource.html
https://github.com/svermaji/Spring-boot-with -hibernate-no-controller
@RepositoryRestController перевизначити згенеровані контролери Spring Data REST із відкритого сховища.
Щоб скористатися перевагами налаштувань Spring Data REST, перетворювачів повідомлень, обробки винятків тощо, використовуйте
@RepositoryRestControllerанотацію замість стандартного Spring MVC@Controllerабо@RestController
Наприклад, ці контролери використовують spring.data.rest.basePathналаштування Spring Boot як базовий шлях для маршрутизації.
Див. Заміна обробників відповідей REST для даних Spring .
Будьте в курсі додавання, @ResponseBodyоскільки воно пропущено@RepositoryRestController
Якщо ви не виставляли сховище (позначене як @RepositoryRestResource(exported = false)), використовуйте @BasePathAwareControllerзамість цього анотацію
Також пам’ятайте про сумки
і
Базовий шлях не відображається в HAL
Вирішення для виправлення посилання: https://stackoverflow.com/a/51736503/548473
ОНОВЛЕННЯ: нарешті я вважаю за краще не використовувати @RepositoryRestControllerчерез багато обхідних шляхів.