Я смотрел на различные примеры использования Spring с REST. Наша конечная цель - установка Spring HATEOAS/HAL
Я видел два разных метода рендеринга REST в Spring
Через @RestController в контроллере
Через @RepositoryRestResource в репозитории
То, что я пытаюсь найти, это то, почему вы используете один поверх другого. При попытке реализовать HAL что лучше?
Наша база данных является Neo4j.
Итак, короткая история в том, что вы хотите использовать @RepositoryRestResource так как это создает сервис HATEOAS с Spring JPA.
Как вы можете видеть здесь, добавляя эту аннотацию и связывая ее с вашим Pojo, вы получаете полнофункциональный сервис HATEOAS без необходимости реализовывать метод репозитория или методы сервиса REST.
Если вы добавите @RestController то вам придется реализовать каждый метод, который вы хотите представить самостоятельно, и он не будет экспортировать его в формат HATEOAS.
Существует третий (и четвертый) вариант, который вы не указали, который должен использовать либо @BasePathAwareController, либо @RepositoryRestController, в зависимости от того, выполняете ли вы действия, специфичные для конкретной организации, или нет.
@RepositoryRestResource используется для установки параметров в общем интерфейсе репозитория - он автоматически создает конечные точки в зависимости от типа расширяемого репозитория (т.е. CrudRepository/PagingAndSortingRepository/etc).
@BasePathAwareController и @RepositoryRestController используются, когда вы хотите вручную создавать конечные точки, но хотите использовать конфигурации Spring Data REST, которые вы настроили.
Если вы используете @RestController, вы создадите параллельный набор конечных точек с различными параметрами конфигурации, то есть другим конвертером сообщений, различными обработчиками ошибок и т.д., но они будут счастливо сосуществовать (и, вероятно, вызвать путаницу).
Конкретную документацию можно найти здесь.
Что ж, приведенные выше ответы верны в их контексте, но я приведу вам практический пример.
Во многих сценариях в рамках API нам необходимо предоставить конечные точки для поиска сущности на основе определенных критериев. Теперь, используя JPA, вам даже не нужно писать запросы, просто создайте интерфейс и методы с определенной номенклатурой Spring-JPA. Для предоставления таких API вы создадите уровень Service, который будет просто вызывать эти методы репозитория, и, наконец, Controllers, которые будут предоставлять конечные точки путем вызова уровня Service.
То, что здесь сделал 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 RESTs, конвертеров сообщений, обработки исключений и
@RepositoryRestControllerдругого, используйте аннотацию@RepositoryRestControllerвместо стандартной Spring MVC@Controllerили@RestController
Например, эти контроллеры используют параметр spring.data.rest.basePath Spring Boot в качестве базового пути для маршрутизации.
См. Переопределение обработчиков ответов REST Spring Data.
Помните о добавлении @ResponseBody поскольку оно отсутствует в @RepositoryRestController
Если вы не @RepositoryRestResource(exported = false) репозиторий (помеченный как @RepositoryRestResource(exported = false)), используйте аннотацию @BasePathAwareController
Также будьте в курсе сумок
а также
Базовый путь не отображается в HAL
Обходной путь для исправления ссылки: fooobar.com/info/2270546/...
ОБНОВЛЕНИЕ: наконец я предпочитаю не использовать @RepositoryRestController из-за большого количества обходных путей.